matplotlib-devel Mailing List for matplotlib (Page 2)

On Dec 14, 2005, at 9:23 AM, Charlie Moad wrote:
> I missed the "New in version 2.4." note in the link I posted. With
> this I would say the current state is probably worth keeping.
Attached is a script which I wrote to make setup.py's more 
declarative and to make using setuptools/py2exe/etc from one file 
less of a pain. The important part is that it also backports 
"package_data" to Python 2.3, which could be ripped out and dropped 
into matplotlib's setup.py without too much trouble.
Ken

I missed the "New in version 2.4." note in the link I posted. With
this I would say the current state is probably worth keeping. Sorry
for the DoS attack of emails on the mailing list this morning. ;)
- Charlie
On 12/14/05, Charlie Moad <cw...@gm...> wrote:
> http://www.python.org/doc/current/dist/node11.html
>
> From this my impression is that the package data files will be placed
> in the same way they are in the package. I will look for a way to get
> around this, and if anyone on the list knows how, please speak up. As
> I said previously, my attempts to use "../../images/*" seemed not to
> work.
>
> On 12/14/05, John Hunter <jdh...@ac...> wrote:
> > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
> >
> > Charlie> Before I do it, you do know that there will be no folder
> > Charlie> heirarchy: e.g. fonts/ttf/*, images... All files will be
> > Charlie> in lib/matplotlib/mpl-data/. I honestly don't think
> > Charlie> there are terribly many files, so shouldn't be a huge
> > Charlie> deal.
> >
> > Is this the only way to do it (no folder hierarchy?). If so, I don't
> > see it as a show stopper. But if it's possible, some form of
> > organization would be cleaner...
> >
> > JDH
> >
>

> try:
> from setuptools.command import bdist_egg
> #from setuptools import setup # use setuptools if possible
> has_setuptools =3D True
> except ImportError:
> from distutils.core import setup
> has_setuptools =3D False
>
Won't setup not be defined if there is an ImportError? This instead?
try:
 from setuptools.command import bdist_egg
 has_setuptools =3D True
except ImportError:
 has_setuptools =3D False
from distutils.core import setup

http://www.python.org/doc/current/dist/node11.html
From this my impression is that the package data files will be placed
in the same way they are in the package. I will look for a way to get
around this, and if anyone on the list knows how, please speak up. As
I said previously, my attempts to use "../../images/*" seemed not to
work.
On 12/14/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
> Charlie> Before I do it, you do know that there will be no folder
> Charlie> heirarchy: e.g. fonts/ttf/*, images... All files will be
> Charlie> in lib/matplotlib/mpl-data/. I honestly don't think
> Charlie> there are terribly many files, so shouldn't be a huge
> Charlie> deal.
>
> Is this the only way to do it (no folder hierarchy?). If so, I don't
> see it as a show stopper. But if it's possible, some form of
> organization would be cleaner...
>
> JDH
>

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> Before I do it, you do know that there will be no folder
 Charlie> heirarchy: e.g. fonts/ttf/*, images... All files will be
 Charlie> in lib/matplotlib/mpl-data/. I honestly don't think
 Charlie> there are terribly many files, so shouldn't be a huge
 Charlie> deal.
Is this the only way to do it (no folder hierarchy?). If so, I don't
see it as a show stopper. But if it's possible, some form of
organization would be cleaner...
JDH

Before I do it, you do know that there will be no folder heirarchy:
e.g. fonts/ttf/*, images...
All files will be in lib/matplotlib/mpl-data/. I honestly don't think
there are terribly many files, so shouldn't be a huge deal.
- Charlie
On 12/14/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
> Charlie> Btw, the best approach would to specify the data as
> Charlie> package-data (since that is what it is), and it would be
> Charlie> the most compatible. Unfortunately my attempt to use
> Charlie> parent directory relative paths failed. Taking this
> Charlie> approach would actually require moving all the mpl data
> Charlie> into the lib/matplotlib/mpl-data directory in cvs. I
> Charlie> thought you might be opposed to that, hence I have the
> Charlie> logic in the setup file.
>
>
> I'm happy to do it in the cleanest and best way so feel free to
> reorganize as necessary, as long as we continue to test on the various
> platforms as you have been doing. You'll need to submit an admin
> request to the sf developers to flush the unused CVS directories after
> the reorganization.
>
> JDH
>

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> Btw, the best approach would to specify the data as
 Charlie> package-data (since that is what it is), and it would be
 Charlie> the most compatible. Unfortunately my attempt to use
 Charlie> parent directory relative paths failed. Taking this
 Charlie> approach would actually require moving all the mpl data
 Charlie> into the lib/matplotlib/mpl-data directory in cvs. I
 Charlie> thought you might be opposed to that, hence I have the
 Charlie> logic in the setup file.
I'm happy to do it in the cleanest and best way so feel free to
reorganize as necessary, as long as we continue to test on the various
platforms as you have been doing. You'll need to submit an admin
request to the sf developers to flush the unused CVS directories after
the reorganization.
JDH

Btw, the best approach would to specify the data as package-data
(since that is what it is), and it would be the most compatible.=20
Unfortunately my attempt to use parent directory relative paths
failed. Taking this approach would actually require moving all the
mpl data into the lib/matplotlib/mpl-data directory in cvs. I thought
you might be opposed to that, hence I have the logic in the setup
file.
- Charlie
On 12/14/05, Charlie Moad <cw...@gm...> wrote:
> That seems a better approach. Did you commit?
>
> On 12/14/05, John Hunter <jdh...@ac...> wrote:
> > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
> >
> > Charlie> I just committed my changes. The simplest approach
> > Charlie> would be to specify the matplotlib module package_data,
> > Charlie> but the current cvs layout doesn't tailor to that very
> > Charlie> well. So I mimicked distutils install command to
> > Charlie> determine where matplotlib is installed. The datapath is
> > Charlie> then defined as $platlib/matplotlib/mpl-data. Why this
> > Charlie> change? If you take a look at
> > Charlie> matplotlib._get_data_path() you will see. This method
> > Charlie> has grown to probably 100 lines of code to check for
> > Charlie> various cases, e.g. py2exe, setuptools, embedding mpl,
> > Charlie> etc. Now that the data is installed into the matplotlib
> > Charlie> module you could pretty much reduce to 1 line:
> > Charlie> "os.sep.join([os.path.dirname(__file__), 'mpl-data'])".
> > Charlie> This now handles all the cases mentioned above. I left
> > Charlie> in the initial check for the MATPLOTLIBDATA env key to
> > Charlie> still allow for some flexibility. I have tested on posix
> > Charlie> and w/wo setuptools. I am going to check windows right
> > Charlie> now, but pretty sure it should work. Please check this
> > Charlie> very carefully before next release as it is a pretty
> > Charlie> major change. Let me know if anyone encounters a
> > Charlie> problem.
> >
> > I'm having some trouble with this on my system. I don't know if
> > something is screwy with my setuptools because I have setuptools but I
> > don't have egg
> >
> > peds-pc311:~/python/projects/matplotlib> python
> > Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
> > [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import setuptools
> > >>> from setuptools.command import bdist_egg
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in ?
> > ImportError: cannot import name bdist_egg
> > >>>
> >
> > and my install fails
> >
> > peds-pc311:~/python/projects/matplotlib> sudo python setup.py install
> > installing data to ./matplotlib/mpl-data
> > running install
> > running build
> > running build_py
> > running build_ext
> > running install_lib
> > running install_data
> > copying matplotlibrc -> /usr/./matplotlib/mpl-data
> >
> >
> > So I replaced the has_setup check with this
> >
> > try:
> > from setuptools.command import bdist_egg
> > #from setuptools import setup # use setuptools if possible
> > has_setuptools =3D True
> > except ImportError:
> > from distutils.core import setup
> > has_setuptools =3D False
> >
> >
> > which works on my system. I hit the same bug with scipy, and the
> > moral seems to be that you should explicitly check for eggs rather
> > than just setuptools, because there are some versions of setuptools
> > floating around w/o eggs.
> >
> > JDH
> >
>

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> That seems a better approach. Did you commit?
Not yet, but I will.
JDH

That seems a better approach. Did you commit?
On 12/14/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
> Charlie> I just committed my changes. The simplest approach
> Charlie> would be to specify the matplotlib module package_data,
> Charlie> but the current cvs layout doesn't tailor to that very
> Charlie> well. So I mimicked distutils install command to
> Charlie> determine where matplotlib is installed. The datapath is
> Charlie> then defined as $platlib/matplotlib/mpl-data. Why this
> Charlie> change? If you take a look at
> Charlie> matplotlib._get_data_path() you will see. This method
> Charlie> has grown to probably 100 lines of code to check for
> Charlie> various cases, e.g. py2exe, setuptools, embedding mpl,
> Charlie> etc. Now that the data is installed into the matplotlib
> Charlie> module you could pretty much reduce to 1 line:
> Charlie> "os.sep.join([os.path.dirname(__file__), 'mpl-data'])".
> Charlie> This now handles all the cases mentioned above. I left
> Charlie> in the initial check for the MATPLOTLIBDATA env key to
> Charlie> still allow for some flexibility. I have tested on posix
> Charlie> and w/wo setuptools. I am going to check windows right
> Charlie> now, but pretty sure it should work. Please check this
> Charlie> very carefully before next release as it is a pretty
> Charlie> major change. Let me know if anyone encounters a
> Charlie> problem.
>
> I'm having some trouble with this on my system. I don't know if
> something is screwy with my setuptools because I have setuptools but I
> don't have egg
>
> peds-pc311:~/python/projects/matplotlib> python
> Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
> [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import setuptools
> >>> from setuptools.command import bdist_egg
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> ImportError: cannot import name bdist_egg
> >>>
>
> and my install fails
>
> peds-pc311:~/python/projects/matplotlib> sudo python setup.py install
> installing data to ./matplotlib/mpl-data
> running install
> running build
> running build_py
> running build_ext
> running install_lib
> running install_data
> copying matplotlibrc -> /usr/./matplotlib/mpl-data
>
>
> So I replaced the has_setup check with this
>
> try:
> from setuptools.command import bdist_egg
> #from setuptools import setup # use setuptools if possible
> has_setuptools =3D True
> except ImportError:
> from distutils.core import setup
> has_setuptools =3D False
>
>
> which works on my system. I hit the same bug with scipy, and the
> moral seems to be that you should explicitly check for eggs rather
> than just setuptools, because there are some versions of setuptools
> floating around w/o eggs.
>
> JDH
>

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> I just committed my changes. The simplest approach
 Charlie> would be to specify the matplotlib module package_data,
 Charlie> but the current cvs layout doesn't tailor to that very
 Charlie> well. So I mimicked distutils install command to
 Charlie> determine where matplotlib is installed. The datapath is
 Charlie> then defined as $platlib/matplotlib/mpl-data. Why this
 Charlie> change? If you take a look at
 Charlie> matplotlib._get_data_path() you will see. This method
 Charlie> has grown to probably 100 lines of code to check for
 Charlie> various cases, e.g. py2exe, setuptools, embedding mpl,
 Charlie> etc. Now that the data is installed into the matplotlib
 Charlie> module you could pretty much reduce to 1 line:
 Charlie> "os.sep.join([os.path.dirname(__file__), 'mpl-data'])".
 Charlie> This now handles all the cases mentioned above. I left
 Charlie> in the initial check for the MATPLOTLIBDATA env key to
 Charlie> still allow for some flexibility. I have tested on posix
 Charlie> and w/wo setuptools. I am going to check windows right
 Charlie> now, but pretty sure it should work. Please check this
 Charlie> very carefully before next release as it is a pretty
 Charlie> major change. Let me know if anyone encounters a
 Charlie> problem.
I'm having some trouble with this on my system. I don't know if
something is screwy with my setuptools because I have setuptools but I
don't have egg
peds-pc311:~/python/projects/matplotlib> python
Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import setuptools
>>> from setuptools.command import bdist_egg
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
ImportError: cannot import name bdist_egg
>>>
and my install fails
peds-pc311:~/python/projects/matplotlib> sudo python setup.py install
installing data to ./matplotlib/mpl-data
running install
running build
running build_py
running build_ext
running install_lib
running install_data
copying matplotlibrc -> /usr/./matplotlib/mpl-data
So I replaced the has_setup check with this
try:
 from setuptools.command import bdist_egg 
 #from setuptools import setup # use setuptools if possible
 has_setuptools = True
except ImportError:
 from distutils.core import setup
 has_setuptools = False
which works on my system. I hit the same bug with scipy, and the
moral seems to be that you should explicitly check for eggs rather
than just setuptools, because there are some versions of setuptools
floating around w/o eggs.
JDH

 
Has anyone worked with quotes_historical_yahoo module enough to know if the
7th attribute, adjusted price, is available? Adjusted price is sort of a
total return figure -- price adjusted for splits and dividends -- and is
actually the critical number to consider for performance over long periods
of time. Finance.quothist in Perl provides this attribute as an option.
 
Steve Miller 

Charlie Moad wrote:
> That's great to hear! Thanks for the info. I am just surprised I
> have not seen this response when it has came up on the twisted list.
I, too, find that bizarre since Twisted and Zope were *the* reasons for that
feature.
-- 
Robert Kern
rob...@gm...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

That's great to hear! Thanks for the info. I am just surprised I
have not seen this response when it has came up on the twisted list.
- Charlie
On 12/12/05, Robert Kern <rob...@gm...> wrote:
> Charlie Moad wrote:
> > The way mpl uses the basemap toolkit will not work using
> > setuptools. This is also an issue that twisted runs into. Since
> > matplotlib will be put in one egg folder and basemap will be stuck in
> > another, trying to import matplotlib.toolkits.basemap will yield an
> > error. Just something to think about for down the road, but its
> > probably not a priority now.
>
> That's why setuptools/eggs have the concept of namespace packages. Both t=
he
> matplotlib egg and basemap egg provide the matplotlib.toolkits namespace =
package.
>
> E.g.:
>
> setup(#...
> namespace_packages=3D['matplotlib.toolkits'],
> )
>
> --
> Robert Kern
> rob...@gm...
>
> "In the fields of hell where the grass grows high
> Are the graves of dreams allowed to die."
> -- Richard Harter
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Charlie Moad wrote:
> The way mpl uses the basemap toolkit will not work using
> setuptools. This is also an issue that twisted runs into. Since
> matplotlib will be put in one egg folder and basemap will be stuck in
> another, trying to import matplotlib.toolkits.basemap will yield an
> error. Just something to think about for down the road, but its
> probably not a priority now.
That's why setuptools/eggs have the concept of namespace packages. Both the
matplotlib egg and basemap egg provide the matplotlib.toolkits namespace package.
E.g.:
setup(#...
 namespace_packages=['matplotlib.toolkits'],
)
-- 
Robert Kern
rob...@gm...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

 The way mpl uses the basemap toolkit will not work using
setuptools. This is also an issue that twisted runs into. Since
matplotlib will be put in one egg folder and basemap will be stuck in
another, trying to import matplotlib.toolkits.basemap will yield an
error. Just something to think about for down the road, but its
probably not a priority now.
- Charlie
On 12/11/05, Andrew Straw <str...@as...> wrote:
> Hi All,
>
> I've added a hopefully innocuous few lines to matplotlib's setup.py:
>
> +
> +try:
> + from setuptools import setup # use setuptools if possible
> +except ImportError:
> + pass
> +
>
> This will use setuptools.setup() to install matplotlib if you have
> setuptools installed on your system. I assume that if you have
> setuptools installed, you want to use it, hence the change. However, I
> thought this may potentially cause issues for folks, so I wanted to
> announce the change here.
>
> This change should have no effect for those without setuptools. If you
> do have setuptools, it also means that the matplotlib data files are now
> placed in the resulting .egg. I've therefore also modified
> _get_data_path() in lib/matplotlib/__init__.py to support this change.
>
> For more information on setuptools, see
> http://peak.telecommunity.com/DevCenter/setuptools
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Charlie Moad wrote:
>FYI, built a bdist_wininst and it worked fine.
>
>
I just tested it too and it works for me with a non-setuptools install,
with a setuptools install, and with a non-setuptools install in which
setuptools was later installed. I think it should be fine.

FYI, built a bdist_wininst and it worked fine.
On 12/12/05, Charlie Moad <cw...@gm...> wrote:
> I just committed my changes. The simplest approach would be to
> specify the matplotlib module package_data, but the current cvs layout
> doesn't tailor to that very well. So I mimicked distutils install
> command to determine where matplotlib is installed. The datapath is
> then defined as $platlib/matplotlib/mpl-data.
> Why this change? If you take a look at
> matplotlib._get_data_path() you will see. This method has grown to
> probably 100 lines of code to check for various cases, e.g. py2exe,
> setuptools, embedding mpl, etc. Now that the data is installed into
> the matplotlib module you could pretty much reduce to 1 line:
> "os.sep.join([os.path.dirname(__file__), 'mpl-data'])". This now
> handles all the cases mentioned above. I left in the initial check
> for the MATPLOTLIBDATA env key to still allow for some flexibility.
> I have tested on posix and w/wo setuptools. I am going to check
> windows right now, but pretty sure it should work. Please check this
> very carefully before next release as it is a pretty major change.
> Let me know if anyone encounters a problem.
>
> Thanks,
> - Charlie
>
> On 12/7/05, John Hunter <jdh...@ac...> wrote:
> > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
> >
> > Charlie> Would it be considered cleaner to embed the mpl data into
> > Charlie> the matplotlib module? This would make it easier to
> > Charlie> clean a mpl install. The data path could be expressed
> > Charlie> fairly easily too, as a one-liner:
> >
> > Charlie> os.sep.join([os.path.split(matplotlib.__file__)[0],
> > Charlie> 'matplotlib-data'])
> >
> > Yes, if you can engineer in a way that works with setup w/ and w/o a
> > --prefix arg it would be preferable, in my view.
> >
> > JDH
> >
>

 I just committed my changes. The simplest approach would be to
specify the matplotlib module package_data, but the current cvs layout
doesn't tailor to that very well. So I mimicked distutils install
command to determine where matplotlib is installed. The datapath is
then defined as $platlib/matplotlib/mpl-data.
 Why this change? If you take a look at
matplotlib._get_data_path() you will see. This method has grown to
probably 100 lines of code to check for various cases, e.g. py2exe,
setuptools, embedding mpl, etc. Now that the data is installed into
the matplotlib module you could pretty much reduce to 1 line:
"os.sep.join([os.path.dirname(__file__), 'mpl-data'])". This now
handles all the cases mentioned above. I left in the initial check
for the MATPLOTLIBDATA env key to still allow for some flexibility.
 I have tested on posix and w/wo setuptools. I am going to check
windows right now, but pretty sure it should work. Please check this
very carefully before next release as it is a pretty major change.=20
Let me know if anyone encounters a problem.
Thanks,
- Charlie
On 12/7/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
> Charlie> Would it be considered cleaner to embed the mpl data into
> Charlie> the matplotlib module? This would make it easier to
> Charlie> clean a mpl install. The data path could be expressed
> Charlie> fairly easily too, as a one-liner:
>
> Charlie> os.sep.join([os.path.split(matplotlib.__file__)[0],
> Charlie> 'matplotlib-data'])
>
> Yes, if you can engineer in a way that works with setup w/ and w/o a
> --prefix arg it would be preferable, in my view.
>
> JDH
>

Hi All,
I've added a hopefully innocuous few lines to matplotlib's setup.py:
+
+try:
+ from setuptools import setup # use setuptools if possible
+except ImportError:
+ pass
+
This will use setuptools.setup() to install matplotlib if you have
setuptools installed on your system. I assume that if you have
setuptools installed, you want to use it, hence the change. However, I
thought this may potentially cause issues for folks, so I wanted to
announce the change here.
This change should have no effect for those without setuptools. If you
do have setuptools, it also means that the matplotlib data files are now
placed in the resulting .egg. I've therefore also modified
_get_data_path() in lib/matplotlib/__init__.py to support this change.
For more information on setuptools, see
http://peak.telecommunity.com/DevCenter/setuptools

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
 Nicholas> I've made a small alteration to my code for AFM mathtext
 Nicholas> to show digits and brackets () in the roman rather than
 Nicholas> the italic font, as is normal in mathtext. The patch is
 Nicholas> attached.
Thanks Nicholas, changes in CVS.
JDH

>>>>> "Rob" == Rob McMullen <rob...@gm...> writes:
 Rob> Here's a small addition to the htdocs to include references
 Rob> to the new EMF backend.
Thanks Rob, I committed these to CVS and they'll show up on the web
next time I do a release and update the web site.
JDH

>>>>> "Philip" == Philip Austin <pa...@eo...> writes:
 Philip> Matlab has a useful contributed function called suptitle.m
 Philip> that puts a central title above a set of subplots:
 Philip> http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=3233&objectType=file
 Philip> I'm planning to do a port for matplotlib, but wanted to
 Philip> check first to see if it's a solved problem -- best, Phil
I believe this is equivalent to something like 
fig.text(0.5, 0.9, 'some text')
where fig is a Figure instance. See
 http://matplotlib.sf.net/matplotlib.figure.html#Figure-text
Exposing subtitle as a pylab function which wraps this functionality
is fine by me.
JDH
 Philip> -------------------------------------------------------
 Philip> This SF.net email is sponsored by: Splunk Inc. Do you grep
 Philip> through log files for problems? Stop! Download the new
 Philip> AJAX search engine that makes searching your log files as
 Philip> easy as surfing the web. DOWNLOAD SPLUNK!
 Philip> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
 Philip> _______________________________________________
 Philip> Matplotlib-devel mailing list
 Philip> Mat...@li...
 Philip> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Matlab has a useful contributed function called suptitle.m that
puts a central title above a set of subplots:
http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=3233&objectType=file
I'm planning to do a port for matplotlib, but wanted to check first to see if
it's a solved problem -- best, Phil Austin

Here's a small addition to the htdocs to include references to the new
EMF backend.
Rob