matplotlib-devel Mailing List for matplotlib (Page 9)

Hi all,
On Thu, Dec 9, 2010 at 23:04, Ben Gamari <bg...@gm...> wrote:
> On 2010年12月09日 16:44:37 -0500, Ben Gamari <bg...@gm...> wrote:
>> rcdefaults()'s implementation appears to implement the latter, updating
>> rcParams from rcParamsDefault in rcsetup.py, which appears to describe
>> the factory default values. Perhaps we should
>> rcParamsDefault.update(rcParams) after loading matplotlibrc?
>>
> As expected, doing the update of rcParamsDefault proposed above (patch
> below) allows the examples.download setting to persist throughout the
> documentation build. It seems like either the documentation build
> process or rcParamsDefault has been badly broken for a very long
> time. Is rcParamsDefault really supposed to be the factory defaults or
> is this just a bug? If the former, we will need to introduce a variant
> of matplotlib.rcdefaults() to reset the configuration to that specified
> in matplotlibrc.
>
> - Ben
>
>
> diff --git a/lib/matplotlib/__init__.py b/lib/matplotlib/__init__.py
> --- a/lib/matplotlib/__init__.py
> +++ b/lib/matplotlib/__init__.py
> @@ -764,13 +772,13 @@ Please do not ask for support with these customizations active.
>
> # this is the instance used by the matplotlib classes
> rcParams = rc_params()
> -
> -rcParamsDefault = RcParams([ (key, default) for key, (default, converter) in \
> -          defaultParams.iteritems() ])
> -
> rcParams['ps.usedistiller'] = checkdep_ps_distiller(rcParams['ps.usedistiller'])
> rcParams['text.usetex'] = checkdep_usetex(rcParams['text.usetex'])
>
> +rcParamsDefault = RcParams([ (key, default) for key, (default, converter) in \
> +           defaultParams.iteritems() ])
> +rcParamsDefault.update(rcParams)
> +
> def rc(group, **kwargs):
>   """
>   Set the current rc params. Group is the grouping for the rc, eg.
With this patch we can indeed finally use the sampledata local dir -
thanks Ben for that!! anyhow, it seems to be quite a radical change,
that might have a bit of impact on what the users can experience, so
I'd like to hear from mpl devels what's the feelings about that.
Anyhow, please note that examples.directory RC param, must not
contains apex (') at the beginning/end of the value, else it would
fail; the example in matplotlibrc.template seems to suggests it's
apex-enclosed:
 #examples.directory : '' # directory to look in if download is false
else you would get:
 IOError: [Errno 2] No such file or directory:
"'/home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/'/axes_grid/bivariate_normal.npy"
it should be made it clearer (or make the get_sample_data() smarter) about that.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Tue, Jan 4, 2011 at 9:15 AM, Derek Homeier <
de...@as...> wrote:
>
>
> With the 64-bit installation on 10.6 I encountered a problem discussed a
> few months
> ago on the list, due to the MacOS module being removed from standard 64-bit
> Python
> builds (and being generally deprecated for Python 3); this had been
> resolved by
> Michiel de Hoon in r8624 (and some parts in r8710, it seems), but those
> changes did
> not make it into rc1. I have attached the patch in the form working for me.
>
Michiel, can you review this and if it looks good contribute it to the 1.0.1
branch?
http://matplotlib.sourceforge.net/devel/coding_guide.html#version-control
Thanks,
JDH

On 04.01.2011, at 1:49AM, Russell E. Owen wrote:
> I have uploaded Mac installers for python.org Python 2.6 and 32-bit
> Python 2.7.
>
> I'm not sure what to do about 64-bit Python 2.7. It does not even
> support Mac OS X 10.5 due to tcl/tk issues that I think were resolved
> too late for python 2.7.1. In my opinion a matplotlib built against
> ActiveState's Python 2.7 (which is 64-bit and supports 10.5 and 10.6)
> might be of more use. Opinions?
I cannot provide much input on those Python installations, but I've 
built rc1
against the fink installations of python/numpy for Intel and PPC 10.5 
as well
as Intel 10.6. I could not reproduce the 
missing .matplotlib/.fontconfig-related
crashes with this build.
With the 64-bit installation on 10.6 I encountered a problem discussed 
a few months
ago on the list, due to the MacOS module being removed from standard 
64-bit Python
builds (and being generally deprecated for Python 3); this had been 
resolved by
Michiel de Hoon in r8624 (and some parts in r8710, it seems), but 
those changes did
not make it into rc1. I have attached the patch in the form working 
for me.
HTH,
						Derek

On 01/03/2011 02:49 PM, Russell E. Owen wrote:
>
> I have uploaded Mac installers for python.org Python 2.6 and 32-bit
> Python 2.7.
>
> I'm not sure what to do about 64-bit Python 2.7. It does not even
> support Mac OS X 10.5 due to tcl/tk issues that I think were resolved
> too late for python 2.7.1. In my opinion a matplotlib built against
> ActiveState's Python 2.7 (which is 64-bit and supports 10.5 and 10.6)
> might be of more use. Opinions?
I'm afraid that would just complicate the situation. What numpy would it 
work with?
Eric
>
> -- Russell
>

On 01/02/2011 05:03 PM, Paul Ivanov wrote:
> I sent this to the -users list a little over a week ago - now
> resending to -devel list against the latest svn.
Paul,
Thanks, I applied your fix to the maintenance branch, so it should 
appear in the 1.0.1 release that is in the works.
I ran into an unrelated conflict when using svnmerge, so getting it into 
the trunk will wait until this can be sorted out.
Eric
>
>
> best,
>

In article 
<AAN...@ma...>,
 John Hunter <jd...@gm...> wrote:
> We are long overdue on getting a bugfix release of 1.0.0 out, so I have
> uploaded an rc for testing at
> 
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
> 
> Christoph and Russell -- if you have time could you build win32 and OSX
> binaries for testing as well. I don't believe either of you have developer
> permissions to upload directly to this site, but I would be happy to add you
> if you send me an sf id. Alternatively, you can upload them to a site of
> your choosing and I'll upload them for you (drop.io was acquired by facebook
> and no longer works).
I have uploaded Mac installers for python.org Python 2.6 and 32-bit 
Python 2.7.
I'm not sure what to do about 64-bit Python 2.7. It does not even 
support Mac OS X 10.5 due to tcl/tk issues that I think were resolved 
too late for python 2.7.1. In my opinion a matplotlib built against 
ActiveState's Python 2.7 (which is 64-bit and supports 10.5 and 10.6) 
might be of more use. Opinions?
-- Russell

In article <4D0...@no...>,
 Christopher Barker <Chr...@no...> wrote:
> On 12/9/10 11:57 PM, Ludwig Schwardt wrote:
> > This patch reminded me to ask why the builtin libpng, zlib and
> > libfreetype on Mac OS 10.5 and later are not used to build Matplotlib,
> 
> It may be because we still want to support OS-X 10.4 .
Yes -- we are still supporting Mac OS X 10.3.9 and later (the same 
versions supported by python.org python).
It will be a relief to stop building those libraries, but they're easy 
enough to build and some of them are newer than the versions originally 
supplied with Mac OS X (including libz and libfreetype) so it's not 
necessarily a bad thing to include static versions.
Regards,
-- Russell

In article <row...@ne...>,
 "Russell E. Owen" <ro...@uw...> wrote:
> In article 
> <AANLkTimbf_uGbX7y9akz6Ned=m8NJNC+R-tnsk__6c7Y-JsoAwUIsXosN+BqQ9rBEUg@public.g
> mane.org>,
> John Hunter <jd...@gm...> wrote:
> 
> > On Mon, Dec 20, 2010 at 6:31 PM, Russell E. Owen 
> > <ro...@uw...> wrote:
> > 
> > > I built a binary installer for matplotlib trunk rev 8843 (because it
> > > leaks memory less than 1.0.0 release). I built it the same way I built
> > > the 1.0.0 binary
> > > <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
> > > l> on Mac OS X 10.4 using python.org Python 2.6.x (where x is probably
> > > 6).
> > >
> > > The binary is available here:
> > > <http://www.astro.washington.edu/users/rowen/python/matplotlib-1.0.0+svn8
> > > 843-python.org-py2.6-macosx10.3.dmg<http://www.astro.washington.edu/users/
> > > ro
> > > wen/python/matplotlib-1.0.0+svn8%0A843-python.org-py2.6-macosx10.3.dmg>
> > > >
> > >
> > > It work fine on Mac OS X 10.4 and 10.5, but on 10.6 attempting to import
> > > pylab almost always segfaults (and the few times I've gotten it to work
> > > on 10.6 I can break it by deleting ~/.fontconfig and ~/.matplotlib and
> > > running Python again). I've tried it on newly created accounts and it
> > > segfaults. Another user of Snow Leopard first reported the problem. So
> > > it's not just me.
> > >
> > > I've appended part of a crash log.
> > >
> > > I built this binary the same way I built the matplotlib 1.0.0 binary,
> > > which has no problems.
> > >
> > 
> > 
> > Could you try a "divide and conquer" approach to narrow down which svn
> > revision introduced the breakage. I realize this is tedious, especially
> > since the bug manifestation is variable, but it if we could figure out the
> > revision number, we'd be more likely to be able to fix it.
> 
> Good suggestion. I tried remaking the an installer for 1.0.0 and it has 
> the exact same issue. I am surprised because I only use the machine for 
> one purpose: making binary installers) and I don't recall rebuilding any 
> of the libraries but either I did or there's been some corruption.
> 
> In any case the good news is that it has nothing to do with matplotlib 
> itself and is all my fault. Presumably libfreetype has gotten corrupted 
> or I built a new version and messed something up. I'll pursue it.
I cleared out /usr/local and rebuilt the necessary libraries and it now 
seems to work fine. I uploaded a new copy of the Mac installer for 
Python 2.6 after performing basic testing on 10.4, 10.5 and 10.6. Please 
give it a try. I'll upload a version for 32-bit Python 2.7 once I have 
it.
-- Russell

In article 
<AANLkTimbf_uGbX7y9akz6Ned=m8N...@ma...>,
 John Hunter <jd...@gm...> wrote:
> On Mon, Dec 20, 2010 at 6:31 PM, Russell E. Owen 
> <ro...@uw...> wrote:
> 
> > I built a binary installer for matplotlib trunk rev 8843 (because it
> > leaks memory less than 1.0.0 release). I built it the same way I built
> > the 1.0.0 binary
> > <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
> > l> on Mac OS X 10.4 using python.org Python 2.6.x (where x is probably
> > 6).
> >
> > The binary is available here:
> > <http://www.astro.washington.edu/users/rowen/python/matplotlib-1.0.0+svn8
> > 843-python.org-py2.6-macosx10.3.dmg<http://www.astro.washington.edu/users/ro
> > wen/python/matplotlib-1.0.0+svn8%0A843-python.org-py2.6-macosx10.3.dmg>
> > >
> >
> > It work fine on Mac OS X 10.4 and 10.5, but on 10.6 attempting to import
> > pylab almost always segfaults (and the few times I've gotten it to work
> > on 10.6 I can break it by deleting ~/.fontconfig and ~/.matplotlib and
> > running Python again). I've tried it on newly created accounts and it
> > segfaults. Another user of Snow Leopard first reported the problem. So
> > it's not just me.
> >
> > I've appended part of a crash log.
> >
> > I built this binary the same way I built the matplotlib 1.0.0 binary,
> > which has no problems.
> >
> 
> 
> Could you try a "divide and conquer" approach to narrow down which svn
> revision introduced the breakage. I realize this is tedious, especially
> since the bug manifestation is variable, but it if we could figure out the
> revision number, we'd be more likely to be able to fix it.
Good suggestion. I tried remaking the an installer for 1.0.0 and it has 
the exact same issue. I am surprised because I only use the machine for 
one purpose: making binary installers) and I don't recall rebuilding any 
of the libraries but either I did or there's been some corruption.
In any case the good news is that it has nothing to do with matplotlib 
itself and is all my fault. Presumably libfreetype has gotten corrupted 
or I built a new version and messed something up. I'll pursue it.
Regards,
-- Russell

On Tue, Dec 21, 2010 at 10:09 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, Dec 15, 2010 at 4:47 PM, Justin Peel <jp...@gm...> wrote:
>
>> I decided to revisit this briefly and found another pretty easy change
>> that gives a fairly significant speed boost for a large number of
>> points. Basically, I just used two list comprehensions instead of
>> looping.
>>
>>
>
> Justin,
>
> I finally had a chance to test this out and it does seem to give a slight
> speedup. It also does make for some cleaner code as well, which is always a
> plus! I still think the main clog, though, is the double for-loops that the
> code is contained in. I will probably take a closer look at it in January
> to see if there is a different way to accomplish the same thing.
>
> Ben Root
>
>
Justin,
I have finally had the chance to make all the commits. There was a slight
modification to your last patch (I made xrange() start at 1 so that ps[i -
1] refers to the first item in ps, not the last). It will not be in the
version 1.0.1 release because I feel that it still needs more testing and
possibly more speed-ups are available. It was committed in r8878 of the
development branch.
Thanks for your efforts!
Ben Root

2010年10月19日 Friedrich Romstedt <fri...@gm...>:
> The test suite passes except for some failures on my 10.6 Mac OS X
> with yesterday checked-out astraw github repo. I'll send them in
> another thread. Let's keep tidy :-) There's more than the symlog
> error mentioned by LittleBigBrain on my sys.
>
> The failures are identical with and without the patch.
>
> Opinions?
There has been no response, so I'm resending together with the patch
file. The patch is created by $ git format-patch -1 on my old git
branch from that time, and can be reapplied by:
$ patch -p1 <0001-Fixing-bug-in-mpl.cm.get_cmap.patch
I cannot test it against recent svn because my gcc on Mac OS X went
havoc after restoring the system from Time Machine (the HDD crashed).
Does anybody know what to do when it cannot find even stdarg.h ????
That time the failures of the test suite did not increase by
introducing the change. And it fixes LittleBigBrain's bug.
Annotations from the git commit are in the patch file. I think it
needs some thinking-through, although I did it carefully, to approve
it.
Btw what happened to the astraw github mirror? The latest commit on
branch "trunk" is from November.
Friedrich

On Mon, Jan 3, 2011 at 2:19 PM, Christoph Gohlke <cg...@uc...> wrote:
>
> These packages should be kept up-to-date if possible. There is an old
> bug report that was closed.
>
> <
> http://sourceforge.net/tracker/index.php?func=detail&aid=3009273&group_id=80706&atid=560720
> >
>
Since the version is out of date and may contain bad tz or tzinfo, I'm
willing to consider it a bug and fixed it in the branch. Seems to be
working fine on my tests.

On Mon, Jan 3, 2011 at 1:57 PM, Russell Owen <ro...@uw...> wrote:
> The news:
> - The Mac binary installer for python.org Python 2.6 works on my Mac OS X
> 10.4 and 10.5 machines (both Intel). However, it segfaults on my 10.6
> machine if there is no existing ~/.matplotlib and ~/.fontconfig. If others
> could test this it would be most helpful. I have not yet tried it on 10.3.9.
>
> To reiterate: a proper test is:
> - delete ~/.matplotlib if it exists
> - delete ~/.fontconfig if it exists
> - run python and try to import pylab or matplotlib
>
> -- Russell
>
If you run an example with --verbose-debug-annoying with a clean cache,
you'll get more information about what font file it is parsing right before
the crash. Not sure if this will help, but it would be interesting to see.
JDH

On 1/3/2011 12:00 PM, Russell Owen wrote:
> matplotlib 1.0.1rc has pytz 2010h but the current version is 2010o.
> (dateutil is current at 1.5).
>
> Should I report this as a bug or is this email sufficient?
>
> -- Russell
>
>
These packages should be kept up-to-date if possible. There is an old 
bug report that was closed.
<http://sourceforge.net/tracker/index.php?func=detail&aid=3009273&group_id=80706&atid=560720>
--
Christoph

On Mon, Jan 3, 2011 at 2:00 PM, Russell Owen <ro...@uw...> wrote:
> matplotlib 1.0.1rc has pytz 2010h but the current version is 2010o.
> (dateutil is current at 1.5).
>
> Should I report this as a bug or is this email sufficient?
>
email is sufficient. I'm inclined to fix this for the trunk (targeting a
1.1 release) rather than the branch as we are aiming for maximum stability
in the branch and 1.0.1 bugfix release. However, if there are known bugs in
the wild vis-a-vid mpl that the old version of pytz is causing us, I am
happy to reconsider.
JDH

matplotlib 1.0.1rc has pytz 2010h but the current version is 2010o. 
(dateutil is current at 1.5).
Should I report this as a bug or is this email sufficient?
-- Russell

The news:
- The Mac binary installer for python.org Python 2.6 works on my Mac 
OS X 10.4 and 10.5 machines (both Intel). However, it segfaults on my 
10.6 machine if there is no existing ~/.matplotlib and ~/.fontconfig. 
If others could test this it would be most helpful. I have not yet 
tried it on 10.3.9.
To reiterate: a proper test is:
- delete ~/.matplotlib if it exists
- delete ~/.fontconfig if it exists
- run python and try to import pylab or matplotlib
-- Russell
On Jan 2, 2011, at 9:52 AM, John Hunter wrote:
> We are long overdue on getting a bugfix release of 1.0.0 out, so I 
> have uploaded an rc for testing at
>
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
>
> Christoph and Russell -- if you have time could you build win32 and 
> OSX binaries for testing as well. I don't believe either of you 
> have developer permissions to upload directly to this site, but I 
> would be happy to add you if you send me an sf id. Alternatively, 
> you can upload them to a site of your choosing and I'll upload them 
> for you (drop.io was acquired by facebook and no longer works).
>
> There are a number of bugs and patches on the tracker that it would 
> have been nice to tackle before this release, but there have been 
> enough improvements in the branch that delaying at this point would 
> be a case of the perfect being the enemy of the good so I think we 
> should move forward now. Nonetheless, if there are important bugs 
> or patches that anyone can tackle before we cut the final release, 
> that would be great.
>
> In sf, we used to be able to tag a file as the preferred file for a 
> given OS, but in the new file manager interface I no longer see a 
> way to do this, so that for example the rc files don't show up as 
> the default download options. Does anyone know how to do this, or 
> perhaps someone can suggest a drop.io replacement that supports 
> multiple user uploaders (eg the different binary builders) and 
> public, no-registration downloads. I googled a bit and didn't find 
> anything that fit the bill.
>
> JDH

I just build and uploaded a version for python 2.6. I have tested it 
on Intel 10.4 and plan to test it on 10.5 and 10.6 before trying to 
build a version for 32-bit Python 2.7. I will keep you posted.
Regards,
-- Russell
On Jan 2, 2011, at 9:52 AM, John Hunter wrote:
> We are long overdue on getting a bugfix release of 1.0.0 out, so I 
> have uploaded an rc for testing at
>
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
>
> Christoph and Russell -- if you have time could you build win32 and 
> OSX binaries for testing as well. I don't believe either of you 
> have developer permissions to upload directly to this site, but I 
> would be happy to add you if you send me an sf id. Alternatively, 
> you can upload them to a site of your choosing and I'll upload them 
> for you (drop.io was acquired by facebook and no longer works).
>
> There are a number of bugs and patches on the tracker that it would 
> have been nice to tackle before this release, but there have been 
> enough improvements in the branch that delaying at this point would 
> be a case of the perfect being the enemy of the good so I think we 
> should move forward now. Nonetheless, if there are important bugs 
> or patches that anyone can tackle before we cut the final release, 
> that would be great.
>
> In sf, we used to be able to tag a file as the preferred file for a 
> given OS, but in the new file manager interface I no longer see a 
> way to do this, so that for example the rc files don't show up as 
> the default download options. Does anyone know how to do this, or 
> perhaps someone can suggest a drop.io replacement that supports 
> multiple user uploaders (eg the different binary builders) and 
> public, no-registration downloads. I googled a bit and didn't find 
> anything that fit the bill.
>
> JDH

On Sun, Jan 2, 2011 at 11:52 AM, John Hunter <jd...@gm...> wrote:
>
>
> In sf, we used to be able to tag a file as the preferred file for a given
> OS, but in the new file manager interface I no longer see a way to do this,
> so that for example the rc files don't show up as the default download
> options.
I found the answer to this -- I don't know why it wasn't working for me
yesterday. In the file manager interface there is a little black icon with
a circle around "i", presumably for "info") in which you can check a button
indicating that this is the default download for a given platform. I could
swear I tried this yesterday...
JDH

It's the annual new year's developer purge, designed to keep the list of
official developers in sync with the people who are currently committing.
The rule of thumb is that someone who has not committed in the last year is
purged. As always, I am happy to reinstate anyone on request, so just email
me.
Slated for removal are sameerd,
mmetz_bn<https://sourceforge.net/project/admin/member_permissions.php?group_id=80706&user_id=1482001>,
pkienzle<https://sourceforge.net/project/admin/member_permissions.php?group_id=80706&user_id=40262>,
evilguru<https://sourceforge.net/project/admin/member_permissions.php?group_id=80706&user_id=1302670>,
 *cmoad*<https://sourceforge.net/project/admin/member_permissions.php?group_id=80706&user_id=705459>,
nnemec<https://sourceforge.net/project/admin/member_permissions.php?group_id=80706&user_id=621175>
The results of this year's run (list is developer and days since most recent
commit):
leejjoon : 5
mdboom : 17
jdh2358 : 21
weathergod : 21
jouni : 29
ryanmay : 48
mdehoon : 73
efiring : 85
fer_perez : 131
heeres : 131
astraw : 133
jrevans : 151
jswhit : 157
dsdale : 167
ianthomas23 : 171
mmetz_bn : 343
sameerd : 476
pkienzle : 503
evilguru : 536
cmoad : 581
dmkaplan : 789
nnemec : 1243
edin1 : 1267
stevech : 1275
kmcivor : 1277
teoliphant : 1369
barrett : 1889
greglielens : 1961
newville : 2057
jvoss2 : 2155
jaytmiller : 2166
perrygreenfield : 2435
jodonoghue : 2561
And the svn log parsing script committed to
examples/misc/developer_commit_history.py
Happy New Year, and thanks for all the hard work!
JDH

On Mon, Dec 20, 2010 at 6:31 PM, Russell E. Owen <ro...@uw...> wrote:
> I built a binary installer for matplotlib trunk rev 8843 (because it
> leaks memory less than 1.0.0 release). I built it the same way I built
> the 1.0.0 binary
> <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
> l> on Mac OS X 10.4 using python.org Python 2.6.x (where x is probably
> 6).
>
> The binary is available here:
> <http://www.astro.washington.edu/users/rowen/python/matplotlib-1.0.0+svn8
> 843-python.org-py2.6-macosx10.3.dmg<http://www.astro.washington.edu/users/rowen/python/matplotlib-1.0.0+svn8%0A843-python.org-py2.6-macosx10.3.dmg>
> >
>
> It work fine on Mac OS X 10.4 and 10.5, but on 10.6 attempting to import
> pylab almost always segfaults (and the few times I've gotten it to work
> on 10.6 I can break it by deleting ~/.fontconfig and ~/.matplotlib and
> running Python again). I've tried it on newly created accounts and it
> segfaults. Another user of Snow Leopard first reported the problem. So
> it's not just me.
>
> I've appended part of a crash log.
>
> I built this binary the same way I built the matplotlib 1.0.0 binary,
> which has no problems.
>
Could you try a "divide and conquer" approach to narrow down which svn
revision introduced the breakage. I realize this is tedious, especially
since the bug manifestation is variable, but it if we could figure out the
revision number, we'd be more likely to be able to fix it.

余亮罡, on 2011年01月03日 13:31, wrote:
> I just do not know how to change the font size,could you tell
> me that? Thank you !
Here's a small example. You can either keep around the ylabel
from when you first create it:
 import matplotlib.pyplot as plt
 lbl = plt.ylabel("foo")
 lbl.set_size(25)
If you already have the labels on an axes:
 ax = plt.gca()
 lbl = ax.yaxis.get_label()
 lbl.set_size('x-small')
Note that ax.get_ylabel() only gets you the string of the
label, which is why you have to use ax.yaxis.get_label() to get
an instance of the matplotlib.text.Text object in order to change
its size.
 
hope that helps,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

Hi Ben:
I just do not know how to change the font size,could you tell me that? Thank you !
At 2011年01月01日 07:08:23,"Benjamin Root" <ben...@ou...> wrote:
2010年12月31日 余亮罡<nu...@16...>
Dear all,
 I have a quesstion about change the width of the ylabel.You know the width of the ylabel is relaete to the x axi,how can i change the width of the ylabel not depend on the width of the x-axis?
 Thank you!
 George
Maybe I am not understanding. The height of the y-axis label text (which is then rotated 90 degrees) is dependent upon the font size, and should already be completely independent of the x-axis. Can you show some examples of what you mean?
Ben Root

I sent this to the -users list a little over a week ago - now
resending to -devel list against the latest svn.
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 
Paul Ivanov, on 2010年12月23日 09:47, wrote:
> Václav Šmilauer, on 2010年12月23日 14:51, wrote:
> > Hi there,
> > 
> > when I use twinx() to have y1 and y2 axes and set ticklabel_format
> > style to 'sci' on the y2 axis, ticks on the y2 are properly numbered,
> > but the "1e-5" that is supposed to be atop y2 appears on the top of
> > y1 instead. When both y1 and y2 use the exponents, they overwrite
> > each other -- a minimal example (result attached in pdf):
> > 
> > import pylab
> > 
> > pylab.plot([0,1e-2,2e-2,3e-2],[1e3,5e3,6.1e3,1e3],'g-')
> > 
> > pylab.ticklabel_format(style='sci',scilimits=(0,0),axis='both') # this is not necessary to show the bug
> > 
> > pylab.twinx()
> > 
> > pylab.plot([1e-2,2e-2,3e-2,4e-2],[2e-5,3e-5,0,-1e-5],'r-')
> > 
> > pylab.ticklabel_format(style='sci',scilimits=(0,0),axis='both') # makes 1e-5 appear on the left instead of on the right
> > 
> > pylab.show()
> > 
> Hi Václav,
> 
> thanks for the bug report. As a temporary workaround - use 
> 
> plt.gca().yaxis.set_offset_position('right')
> 
> Committers: the patch attached fixes this problem. I thought that
> there might be a similar problem for twiny() - but ax.xaxis does
> not appear to have .set_offset_position() method.
> 
> > I've had this issue with versions .99, 1.0.0, running on Linux
> > (Ubuntu, versions 9.04 through to 10.10).
> 
> me too, and I kept forgetting to report it.
> 
> > PS. what's wrong with the sf.net bugzilla? I was not able to post the
> > issue there --
> 
> this I do not know.
> 

On Mon, Jan 3, 2011 at 00:21, Ben Gamari <bga...@gm...> wrote:
> On Sun, 2 Jan 2011 23:25:12 +0100, Sandro Tosi <mo...@de...> wrote:
>> Maybe I just missed them, but I can't find in the tarball the data
>> files needed to run the examples without internet connection. I
>> thought it was decided to ship them directly in the tarball and so use
>> the examples.directory rc option to point to them at build-time and
>> avoid to download, but if they're not in the tarball.... :)
>>
> You might consider looking at my Ubuntu PPA[1] if you are going to work on
> packaging. I seem to have everything working at this point, so perhaps
> that can save you some work.
I already looked at it, but it still needs some work.
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi