matplotlib-devel Mailing List for matplotlib (Page 8)

On Wed, Jan 5, 2011 at 18:45, John Hunter <jd...@gm...> wrote:
> On Wed, Jan 5, 2011 at 11:41 AM, Sandro Tosi <mo...@de...> wrote:
>>
>> > +def rc_file_defaults():
>> > +  """
>> > +  Restore the default rc params from the original matplotlib rc that
>> > +  was loaded
>> > +  """
>> > +  rcParams.update(rcParamsOrig)
>> > +
>> > _use_error_msg = """ This call to matplotlib.use() has no effect
>> > because the the backend has already been chosen;
>> > matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
>>
>>
>> I take the patch is not complete, right? because naively applying it
>> in a just-untarred source code + configuring doc/matplotlibrc don't
>> work (ie keeps trying accessing the net)
>>
>
>
> Well, that is the default behavior. You still have to untar, and set the
> examples.directory rc parameter as Ben discussed to do a no download doc
> build. So you'll want to patch doc/matplotlibrc to set this param.
ehm that's what I meant with "configuring doc/matplotlibrc" - I did that :)
$ tail -n2 doc/matplotlibrc
examples.download : False # False to bypass downloading mechanism
examples.directory : /home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/
and sampledata is .. from doc
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 5, 2011 at 11:41 AM, Sandro Tosi <mo...@de...> wrote:
> > +def rc_file_defaults():
> > + """
> > + Restore the default rc params from the original matplotlib rc that
> > + was loaded
> > + """
> > + rcParams.update(rcParamsOrig)
> > +
> > _use_error_msg = """ This call to matplotlib.use() has no effect
> > because the the backend has already been chosen;
> > matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
>
>
> I take the patch is not complete, right? because naively applying it
> in a just-untarred source code + configuring doc/matplotlibrc don't
> work (ie keeps trying accessing the net)
>
>
Well, that is the default behavior. You still have to untar, and set the
examples.directory rc parameter as Ben discussed to do a no download doc
build. So you'll want to patch doc/matplotlibrc to set this param.
JDH

On Wed, Jan 5, 2011 at 11:11 AM, Benjamin Root <ben...@ou...> wrote:
> On Wed, Jan 5, 2011 at 10:33 AM, Benjamin Root <ben...@ou...> wrote:
>
>> On Wed, Jan 5, 2011 at 10:08 AM, Christoph Gohlke <cg...@uc...>wrote:
>>
>>> Not sure if this should hold the release but 1.0.1rc fails to run two
>>> examples (contourf_log.py and pcolor_log.py) as described in bug
>>> #3143748 "Math domain error in ticker.py is_decade()"
>>> <
>>> http://sourceforge.net/tracker/?func=detail&aid=3143748&group_id=80706&atid=560720
>>> >
>>>
>>> Christoph
>>>
>>> On 1/5/2011 5:36 AM, John Hunter wrote:
>>> > OK, I'm not aware of any outstanding issues that should hold this
>>> > release. If there are any, please let me know, else I'll upload the
>>> > final later today.
>>> >
>>> > On Wed, Jan 5, 2011 at 7:33 AM, Michiel de Hoon <mjl...@ya...
>>> > <mailto:mjl...@ya...>> wrote:
>>> >
>>> > Done.
>>> >
>>> > Thanks,
>>> > --Michiel.
>>> >
>>> >
>>>
>>>
>> The fix that was applied to the development branch should have also been
>> applied to the maintenance branch as well, but it appears that it wasn't.
>> The fix given in r8873 is correct, though. Adding the np.abs() fixes the
>> domain error. Taking the lx calculation out would mess things up for those
>> who are using various offsets for their plots.
>>
>> Although, looking at the code closer, I have to wonder if it is still
>> correct because of the "nearest_long()" function. Doesn't python already
>> have established rounding functions that should be used for these things?
>>
>> Anyway, I don't know why the tickers for the colorbars are wrong... the
>> contourf_log.py code uses locator=ticker.LogLocator() and the pcolor_log.py
>> code uses norm=LogNorm(). These are two different approaches, and the tick
>> labels are still wrong. Does anybody else have any insight on this?
>>
>> Ben Root
>>
>>
> Interesting... if I use format=ticker.LogFormatter(labelOnlyBase=False) in
> the call to colorbar, it works as expected. Even more interesting, if I use
> format=ticker.LogFormatterMathtext() or
> format=ticker.LogFormatterExponent(), it also works as expected (even though
> labelOnlyBase=True for those two...).
>
> btw, I would be nice if LogFormatterMathtext() was used instead of
> LogFormatter() for the default for colorbar. It appears that this is the
> case for regular plots, so I don't know why the same doesn't happen for
> colorbars (but that's for another day...).
>
> Ben Root
>
>
It appears that in the call for LogFormatter(), it calls is_decade(), while
LogFormatterExponent() and LogFormatterMathtext() are using
is_close_to_int() instead of is_decade(). Should LogFormatter() be changed
to use is_close_to_int() or was the use of is_close_to_int() a temporary
workaround with some issue in is_decade()?
Ben Root

Hi John,
On Wed, Jan 5, 2011 at 15:04, John Hunter <jd...@gm...> wrote:
> I agree the current behavior needs to be improved. I'm testing a change now
> which utilizes two functions, now properly documented, and removing the hack
> in the plot_directive since the file defaults will be preserved. This keeps
> the current behavior, since rcdefaults is unchanged, but fixes the doc
> string, and introduces a new function with the desired behavior.
thanks for working on it!
> Index: doc/matplotlibrc
> ===================================================================
> --- doc/matplotlibrc  (revision 8886)
> +++ doc/matplotlibrc  (working copy)
> @@ -232,7 +232,7 @@
>
> ### FIGURE
> # See http://matplotlib.sourceforge.net/matplotlib.figure.html#Figure
> -figure.figsize  : 6, 4  # figure size in inches
> +figure.figsize  : 5.5, 4.5  # figure size in inches
> #figure.dpi    : 80   # figure dots per inch
> #figure.facecolor : 0.75  # figure facecolor; 0.75 is scalar gray
> #figure.edgecolor : white  # figure edgecolor
> Index: lib/matplotlib/__init__.py
> ===================================================================
> --- lib/matplotlib/__init__.py (revision 8886)
> +++ lib/matplotlib/__init__.py (working copy)
> @@ -762,6 +762,7 @@
>
> # this is the instance used by the matplotlib classes
> rcParams = rc_params()
> +rcParamsOrig = rcParams.copy()
>
> rcParamsDefault = RcParams([ (key, default) for key, (default, converter)
> in \
>           defaultParams.iteritems() ])
> @@ -843,11 +844,19 @@
>
> def rcdefaults():
>   """
> -  Restore the default rc params - the ones that were created at
> -  matplotlib load time.
> +  Restore the default rc params - these are not the params loaded by
> +  the rc file, but mpl's internal params. See rc_file_defaults for
> +  reloading the default params from the rc file
>   """
>   rcParams.update(rcParamsDefault)
>
> +def rc_file_defaults():
> +  """
> +  Restore the default rc params from the original matplotlib rc that
> +  was loaded
> +  """
> +  rcParams.update(rcParamsOrig)
> +
> _use_error_msg = """ This call to matplotlib.use() has no effect
> because the the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
I take the patch is not complete, right? because naively applying it
in a just-untarred source code + configuring doc/matplotlibrc don't
work (ie keeps trying accessing the net)
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Wed, Jan 5, 2011 at 11:21 AM, John Hunter <jd...@gm...> wrote:
>
>
> On Wed, Jan 5, 2011 at 11:17 AM, John Hunter <jd...@gm...> wrote:
>
>>
>>
>> Very strange -- this is what I am doing for a clean build and install.
>> Can't see where I am going wrong...
>> I'm also having the same problem on two platofrms (python2.4 solaris,
>> python2.6 linux)
>>
>>
>> jdhunter@uqbar:mpl1> rm -rf build
>> ~/dev/lib/python2.6/site-packages/matplotlib* ~/.matplotlib/*cache*
>>
>
>
> I found the problem -- failed to flush mpl_toolkits for the clean install.
> Line should read:
>
>
> > rm -rf build ~/dev/lib/python2.6/site-packages/matplotlib*
> ~/.matplotlib/*cache* ~/dev/lib/python2.6/site-packages/mpl_toolkits/
>
> Sorry for the noise! Note to self -- start using virtualevn...
>
> JDH
>
>
No worries!
As a side note, I have been using:
python setupegg.py develop --user
for the past year with very few headaches. It makes an egg.lnk file (in the
~/.local directory) that points back to the current code directory. Some
things might get wonky with respect to things that have to be recompiled,
but for pure python changes, it works very nicely. I can't remember if it
works in RHEL5, though...
Ben Root

On Wed, Jan 5, 2011 at 11:17 AM, John Hunter <jd...@gm...> wrote:
>
>
> Very strange -- this is what I am doing for a clean build and install.
> Can't see where I am going wrong...
> I'm also having the same problem on two platofrms (python2.4 solaris,
> python2.6 linux)
>
>
> jdhunter@uqbar:mpl1> rm -rf build
> ~/dev/lib/python2.6/site-packages/matplotlib* ~/.matplotlib/*cache*
>
I found the problem -- failed to flush mpl_toolkits for the clean install.
Line should read:
> rm -rf build ~/dev/lib/python2.6/site-packages/matplotlib*
~/.matplotlib/*cache* ~/dev/lib/python2.6/site-packages/mpl_toolkits/
Sorry for the noise! Note to self -- start using virtualevn...
JDH

On Wed, Jan 5, 2011 at 10:33 AM, Benjamin Root <ben...@ou...> wrote:
> On Wed, Jan 5, 2011 at 10:08 AM, Christoph Gohlke <cg...@uc...> wrote:
>
>> Not sure if this should hold the release but 1.0.1rc fails to run two
>> examples (contourf_log.py and pcolor_log.py) as described in bug
>> #3143748 "Math domain error in ticker.py is_decade()"
>> <
>> http://sourceforge.net/tracker/?func=detail&aid=3143748&group_id=80706&atid=560720
>> >
>>
>> Christoph
>>
>> On 1/5/2011 5:36 AM, John Hunter wrote:
>> > OK, I'm not aware of any outstanding issues that should hold this
>> > release. If there are any, please let me know, else I'll upload the
>> > final later today.
>> >
>> > On Wed, Jan 5, 2011 at 7:33 AM, Michiel de Hoon <mjl...@ya...
>> > <mailto:mjl...@ya...>> wrote:
>> >
>> > Done.
>> >
>> > Thanks,
>> > --Michiel.
>> >
>> >
>>
>>
> The fix that was applied to the development branch should have also been
> applied to the maintenance branch as well, but it appears that it wasn't.
> The fix given in r8873 is correct, though. Adding the np.abs() fixes the
> domain error. Taking the lx calculation out would mess things up for those
> who are using various offsets for their plots.
>
> Although, looking at the code closer, I have to wonder if it is still
> correct because of the "nearest_long()" function. Doesn't python already
> have established rounding functions that should be used for these things?
>
> Anyway, I don't know why the tickers for the colorbars are wrong... the
> contourf_log.py code uses locator=ticker.LogLocator() and the pcolor_log.py
> code uses norm=LogNorm(). These are two different approaches, and the tick
> labels are still wrong. Does anybody else have any insight on this?
>
> Ben Root
>
>
Interesting... if I use format=ticker.LogFormatter(labelOnlyBase=False) in
the call to colorbar, it works as expected. Even more interesting, if I use
format=ticker.LogFormatterMathtext() or
format=ticker.LogFormatterExponent(), it also works as expected (even though
labelOnlyBase=True for those two...).
btw, I would be nice if LogFormatterMathtext() was used instead of
LogFormatter() for the default for colorbar. It appears that this is the
case for regular plots, so I don't know why the same doesn't happen for
colorbars (but that's for another day...).
Ben Root

On Wed, Jan 5, 2011 at 10:44 AM, Benjamin Root <ben...@ou...> wrote:
> On Wed, Jan 5, 2011 at 10:41 AM, John Hunter <jd...@gm...> wrote:
>
>>
>>
>> On Wed, Jan 5, 2011 at 10:38 AM, John Hunter <jd...@gm...> wrote:
>>
>>>
>>> I tried the naive fix in lines.py
>>>
>>> def set_axes(self, ax):
>>> Artist.set_axes(self, ax)
>>> if getattr(ax, 'xaxis', None):
>>> self._xcid = ax.xaxis.callbacks.connect('units',
>>> self.recache_always)
>>> if getattr(ax, 'yaxis', None) is not None:
>>> self._ycid = ax.yaxis.callbacks.connect('units',
>>> self.recache_always)
>>> set_axes.__doc__ = Artist.set_axes.__doc__
>>>
>>>
>>
>> Oops, type in my naieve fix. Should read
>>
>>
>> def set_axes(self, ax):
>> Artist.set_axes(self, ax)
>> if getattr(ax, 'xaxis', None) is not None:
>>
>> self._xcid = ax.xaxis.callbacks.connect('units',
>> self.recache_always)
>> if getattr(ax, 'yaxis', None) is not None:
>> self._ycid = ax.yaxis.callbacks.connect('units',
>> self.recache_always)
>> set_axes.__doc__ = Artist.set_axes.__doc__
>>
>> but the problem remains.
>>
>>
> Hmmm, let me check it out... I hope it wasn't one of my patches that did
> it....
>
> Ben Root
>
>
I initially had problems (although with the gtkagg backend...), but then I
moved my development branch build to another directory to effectively hide
it and then rebuilt the 1.0.1 branch, and everything worked fine. Maybe
there was something in the build process that got messed up?
Ben Root

On Wed, Jan 5, 2011 at 10:41 AM, John Hunter <jd...@gm...> wrote:
>
>
> On Wed, Jan 5, 2011 at 10:38 AM, John Hunter <jd...@gm...> wrote:
>
>>
>> I tried the naive fix in lines.py
>>
>> def set_axes(self, ax):
>> Artist.set_axes(self, ax)
>> if getattr(ax, 'xaxis', None):
>> self._xcid = ax.xaxis.callbacks.connect('units',
>> self.recache_always)
>> if getattr(ax, 'yaxis', None) is not None:
>> self._ycid = ax.yaxis.callbacks.connect('units',
>> self.recache_always)
>> set_axes.__doc__ = Artist.set_axes.__doc__
>>
>>
>
> Oops, type in my naieve fix. Should read
>
>
> def set_axes(self, ax):
> Artist.set_axes(self, ax)
> if getattr(ax, 'xaxis', None) is not None:
>
> self._xcid = ax.xaxis.callbacks.connect('units',
> self.recache_always)
> if getattr(ax, 'yaxis', None) is not None:
> self._ycid = ax.yaxis.callbacks.connect('units',
> self.recache_always)
> set_axes.__doc__ = Artist.set_axes.__doc__
>
> but the problem remains.
>
>
Hmmm, let me check it out... I hope it wasn't one of my patches that did
it....
Ben Root

On Wed, Jan 5, 2011 at 10:38 AM, John Hunter <jd...@gm...> wrote:
>
> I tried the naive fix in lines.py
>
> def set_axes(self, ax):
> Artist.set_axes(self, ax)
> if getattr(ax, 'xaxis', None):
> self._xcid = ax.xaxis.callbacks.connect('units',
> self.recache_always)
> if getattr(ax, 'yaxis', None) is not None:
> self._ycid = ax.yaxis.callbacks.connect('units',
> self.recache_always)
> set_axes.__doc__ = Artist.set_axes.__doc__
>
>
Oops, type in my naieve fix. Should read
 def set_axes(self, ax):
 Artist.set_axes(self, ax)
 if getattr(ax, 'xaxis', None) is not None:
 self._xcid = ax.xaxis.callbacks.connect('units',
self.recache_always)
 if getattr(ax, 'yaxis', None) is not None:
 self._ycid = ax.yaxis.callbacks.connect('units',
self.recache_always)
 set_axes.__doc__ = Artist.set_axes.__doc__
but the problem remains.

This appears to have escaped my tests :-(
All of the 3d examples are failing on the 1.0.1 branch -- can anyone
replicate this?
johnh@udesktop253:mplot3d> python subplot3d_demo.py
Traceback (most recent call last):
 File "subplot3d_demo.py", line 14, in ?
 ax = fig.add_subplot(1, 2, 1, projection='3d')
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/figure.py",
line 687, in add_subplot
 a = subplot_class_factory(projection_class)(self, *args, **kwargs)
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/axes.py", line
8380, in __init__
 self._axes_class.__init__(self, fig, self.figbox, **kwargs)
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/mplot3d/axes3d.py",
line 76, in __init__
 frameon=True,
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/axes.py", line
448, in __init__
 self._init_axis()
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/mplot3d/axes3d.py",
line 110, in _init_axis
 self.xy_dataLim.intervalx, self)
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/mplot3d/axis3d.py",
line 89, in __init__
 self.axes._set_artist_props(self.line)
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/axes.py", line
780, in _set_artist_props
 a.set_axes(self)
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/lines.py",
line 397, in set_axes
 if ax.xaxis is not None:
AttributeError: 'Axes3DSubplot' object has no attribute 'xaxis'
I tried the naive fix in lines.py
 def set_axes(self, ax):
 Artist.set_axes(self, ax)
 if getattr(ax, 'xaxis', None):
 self._xcid = ax.xaxis.callbacks.connect('units',
self.recache_always)
 if getattr(ax, 'yaxis', None) is not None:
 self._ycid = ax.yaxis.callbacks.connect('units',
self.recache_always)
 set_axes.__doc__ = Artist.set_axes.__doc__
but this just pushed the bug downstream
johnh@udesktop253:mplot3d> python subplot3d_demo.py
Traceback (most recent call last):
 File "subplot3d_demo.py", line 14, in ?
 ax = fig.add_subplot(1, 2, 1, projection='3d')
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/figure.py",
line 687, in add_subplot
 a = subplot_class_factory(projection_class)(self, *args, **kwargs)
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/axes.py", line
8380, in __init__
 self._axes_class.__init__(self, fig, self.figbox, **kwargs)
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/mplot3d/axes3d.py",
line 76, in __init__
 frameon=True,
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/axes.py", line
448, in __init__
 self._init_axis()
 File
"/home/titan/johnh/dev/lib/python2.4/site-packages/mpl_toolkits/mplot3d/axes3d.py",
line 120, in _init_axis
 ax.init3d()
AttributeError: 'XAxis' object has no attribute 'init3d'
Perhaps someone with more understanding of 3D internals can correct this?

On Wed, Jan 5, 2011 at 10:08 AM, Christoph Gohlke <cg...@uc...> wrote:
> Not sure if this should hold the release but 1.0.1rc fails to run two
> examples (contourf_log.py and pcolor_log.py) as described in bug
> #3143748 "Math domain error in ticker.py is_decade()"
> <
> http://sourceforge.net/tracker/?func=detail&aid=3143748&group_id=80706&atid=560720
> >
>
> Christoph
>
> On 1/5/2011 5:36 AM, John Hunter wrote:
> > OK, I'm not aware of any outstanding issues that should hold this
> > release. If there are any, please let me know, else I'll upload the
> > final later today.
> >
> > On Wed, Jan 5, 2011 at 7:33 AM, Michiel de Hoon <mjl...@ya...
> > <mailto:mjl...@ya...>> wrote:
> >
> > Done.
> >
> > Thanks,
> > --Michiel.
> >
> >
>
>
The fix that was applied to the development branch should have also been
applied to the maintenance branch as well, but it appears that it wasn't.
The fix given in r8873 is correct, though. Adding the np.abs() fixes the
domain error. Taking the lx calculation out would mess things up for those
who are using various offsets for their plots.
Although, looking at the code closer, I have to wonder if it is still
correct because of the "nearest_long()" function. Doesn't python already
have established rounding functions that should be used for these things?
Anyway, I don't know why the tickers for the colorbars are wrong... the
contourf_log.py code uses locator=ticker.LogLocator() and the pcolor_log.py
code uses norm=LogNorm(). These are two different approaches, and the tick
labels are still wrong. Does anybody else have any insight on this?
Ben Root

On Wed, Jan 5, 2011 at 9:51 AM, John Hunter <jd...@gm...> wrote:
>
>
> On Wed, Jan 5, 2011 at 9:45 AM, Benjamin Root <ben...@ou...> wrote:
>
>>
>> Ah, I see... that makes much more sense then.
>>
>> Thanks for clearing that up.
>>
>
>
> Ben do you want to handle this submission? Since it is a bug, it can go
> into the branch.
>
> Paul, would you like to have commit access? If so, please send me your sf
> id.
>
> Thanks!
> JDH
>
Looks like Jae-Joon beat me to it.
Ben Root

Not sure if this should hold the release but 1.0.1rc fails to run two 
examples (contourf_log.py and pcolor_log.py) as described in bug 
#3143748 "Math domain error in ticker.py is_decade()" 
<http://sourceforge.net/tracker/?func=detail&aid=3143748&group_id=80706&atid=560720>
Christoph
On 1/5/2011 5:36 AM, John Hunter wrote:
> OK, I'm not aware of any outstanding issues that should hold this
> release. If there are any, please let me know, else I'll upload the
> final later today.
>
> On Wed, Jan 5, 2011 at 7:33 AM, Michiel de Hoon <mjl...@ya...
> <mailto:mjl...@ya...>> wrote:
>
> Done.
>
> Thanks,
> --Michiel.
>
>

On Wed, Jan 5, 2011 at 9:45 AM, Benjamin Root <ben...@ou...> wrote:
>
> Ah, I see... that makes much more sense then.
>
> Thanks for clearing that up.
>
Ben do you want to handle this submission? Since it is a bug, it can go
into the branch.
Paul, would you like to have commit access? If so, please send me your sf
id.
Thanks!
JDH

Thanks for the patches.
I just committed the getitem patch to the trunk with slight modifications.
As I think this is not a serious bug, I didn't push it to the
maintenance branch.
I'll review the doc patch and commit it later this week.
On the other hand, I don't think it is a good idea to have the
GridSpec iterable.
While the code below could be handy,
 outer_grid = GridSpec(4, 4)
 for cell in outer_grid:
 ...
It could be confusing as the code below would not work.
for cell in outer_grid[:]:
 ...
In other words,
iter(outer_grid) != iter(outer_grid[:]).
outer_grid[:] is not iterable actually.
So my current inclination is to force the GridSpec also not iterable.
How others think?
Regards,
-JJ

On Wed, Jan 5, 2011 at 7:40 AM, Sandro Tosi <mo...@de...> wrote:
>
>
> Could you please give your opinion on the documentation &
> example.download issue on the other thread?
>
>
Thanks for the reminder. I commented in the other thread.
JDH

On Wed, Jan 5, 2011 at 12:11 AM, Paul Ivanov <piv...@gm...> wrote:
> Benjamin Root, on 2011年01月04日 19:48, wrote:
> > 2011年1月4日 Paul Ivanov <piv...@gm...>
> >
> > > Hi matplotlib developers,
> > >
> > > I was answering a question on the -users list and came across a
> > > gridspec __getitem__ bug which causes an infinite loop if the
> > > user tries to iterate over it, because getitem never did a
> > > sanity-check when given an integer key.
> > >
> > > from matplotlib import gridspec
> > > gs = gridspec.GridSpec(1,2)
> > > gs[100] # no error is given, a SubplotSpec is returned
> > > [x for x in gs] # causes infinite loop before applying patch
> > Does this patch prevent the use of negative indexes? If so, then we
> might
> > want to rethink that in order to be more consistent with numpy arrays and
> > python lists...
>
> No, it does not prevent the use of negative indexes, and ensures
> that the negative index is within the allowed bounds, so we do
> the right thing. Here's the full patch for context:
>
> lib/matplotlib/gridspec.py
> 169 else:
> 170 if key < 0:
> 171 key += total
> 172+ if key >= total or key < 0:
> 173+ raise IndexError("index out of range")
> 174 num1, num2 = key, None
>
>
> As you can see, the reason line 172 has the key < 0 check is
> because the allowed range of negative indexes gets dealt with on
> the two preceding lines. So for gs=gridspec.GridSpec(1,2);
> Both gs[-1] and gs[-2] are legal, but gs[-3] will raise an
> IndexError.
>
> --
> Paul Ivanov
> 314 address only used for lists, off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
Ah, I see... that makes much more sense then.
Thanks for clearing that up.
Ben Root

On Tue, Jan 4, 2011 at 4:40 PM, Sandro Tosi <mo...@de...> wrote:
> 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.
>
I agree the current behavior needs to be improved. I'm testing a change now
which utilizes two functions, now properly documented, and removing the hack
in the plot_directive since the file defaults will be preserved. This keeps
the current behavior, since rcdefaults is unchanged, but fixes the doc
string, and introduces a new function with the desired behavior.
Index: doc/matplotlibrc
===================================================================
--- doc/matplotlibrc (revision 8886)
+++ doc/matplotlibrc (working copy)
@@ -232,7 +232,7 @@
 ### FIGURE
 # See http://matplotlib.sourceforge.net/matplotlib.figure.html#Figure
-figure.figsize : 6, 4 # figure size in inches
+figure.figsize : 5.5, 4.5 # figure size in inches
 #figure.dpi : 80 # figure dots per inch
 #figure.facecolor : 0.75 # figure facecolor; 0.75 is scalar gray
 #figure.edgecolor : white # figure edgecolor
Index: lib/matplotlib/__init__.py
===================================================================
--- lib/matplotlib/__init__.py (revision 8886)
+++ lib/matplotlib/__init__.py (working copy)
@@ -762,6 +762,7 @@
 # this is the instance used by the matplotlib classes
 rcParams = rc_params()
+rcParamsOrig = rcParams.copy()
 rcParamsDefault = RcParams([ (key, default) for key, (default, converter)
in \
 defaultParams.iteritems() ])
@@ -843,11 +844,19 @@
 def rcdefaults():
 """
- Restore the default rc params - the ones that were created at
- matplotlib load time.
+ Restore the default rc params - these are not the params loaded by
+ the rc file, but mpl's internal params. See rc_file_defaults for
+ reloading the default params from the rc file
 """
 rcParams.update(rcParamsDefault)
+def rc_file_defaults():
+ """
+ Restore the default rc params from the original matplotlib rc that
+ was loaded
+ """
+ rcParams.update(rcParamsOrig)
+
 _use_error_msg = """ This call to matplotlib.use() has no effect
 because the the backend has already been chosen;
 matplotlib.use() must be called *before* pylab, matplotlib.pyplot,

Hi John.
On Wed, Jan 5, 2011 at 14:36, John Hunter <jd...@gm...> wrote:
> OK, I'm not aware of any outstanding issues that should hold this release.
> If there are any, please let me know, else I'll upload the final later
> today.
Could you please give your opinion on the documentation &
example.download issue on the other thread?
Thanks & cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

OK, I'm not aware of any outstanding issues that should hold this release.
If there are any, please let me know, else I'll upload the final later
today.
On Wed, Jan 5, 2011 at 7:33 AM, Michiel de Hoon <mjl...@ya...> wrote:
> Done.
>
> Thanks,
> --Michiel.
>
>

Done.
Thanks,
--Michiel.
--- On Tue, 1/4/11, John Hunter <jd...@gm...> wrote:
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
 

Benjamin Root, on 2011年01月04日 19:48, wrote:
> 2011年1月4日 Paul Ivanov <piv...@gm...>
> 
> > Hi matplotlib developers,
> >
> > I was answering a question on the -users list and came across a
> > gridspec __getitem__ bug which causes an infinite loop if the
> > user tries to iterate over it, because getitem never did a
> > sanity-check when given an integer key.
> >
> > from matplotlib import gridspec
> > gs = gridspec.GridSpec(1,2)
> > gs[100] # no error is given, a SubplotSpec is returned
> > [x for x in gs] # causes infinite loop before applying patch
> Does this patch prevent the use of negative indexes? If so, then we might
> want to rethink that in order to be more consistent with numpy arrays and
> python lists...
No, it does not prevent the use of negative indexes, and ensures
that the negative index is within the allowed bounds, so we do
the right thing. Here's the full patch for context:
lib/matplotlib/gridspec.py
169 else:
170 if key < 0:
171 key += total
172+ if key >= total or key < 0:
173+ raise IndexError("index out of range")
174 num1, num2 = key, None
As you can see, the reason line 172 has the key < 0 check is
because the allowed range of negative indexes gets dealt with on
the two preceding lines. So for gs=gridspec.GridSpec(1,2);
Both gs[-1] and gs[-2] are legal, but gs[-3] will raise an
IndexError.
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

2011年1月4日 Paul Ivanov <piv...@gm...>
> Hi matplotlib developers,
>
> I was answering a question on the -users list and came across a
> gridspec __getitem__ bug which causes an infinite loop if the
> user tries to iterate over it, because getitem never did a
> sanity-check when given an integer key.
>
> from matplotlib import gridspec
> gs = gridspec.GridSpec(1,2)
> gs[100] # no error is given, a SubplotSpec is returned
> [x for x in gs] # causes infinite loop before applying patch
>
> # after applying the patch - which is just lines 171-172 in the
> # traceback below
> In [9]: gs[100]
> ----------------------------------------------------------
> IndexError Traceback (most recent call last)
>
> ./matplotlib/<ipython console> in <module>()
>
> ./matplotlib/gridspec.pyc
> in __getitem__(self, key)
> 170 key += total
> 171 if key >= total or key < 0:
> --> 172 raise IndexError("index out of range")
> 173 num1, num2 = key, None
> 174
>
> IndexError: index out of range
>
>
Does this patch prevent the use of negative indexes? If so, then we might
want to rethink that in order to be more consistent with numpy arrays and
python lists...
Ben Root

Hi matplotlib developers,
I was answering a question on the -users list and came across a
gridspec __getitem__ bug which causes an infinite loop if the
user tries to iterate over it, because getitem never did a
sanity-check when given an integer key.
 from matplotlib import gridspec
 gs = gridspec.GridSpec(1,2)
 gs[100] # no error is given, a SubplotSpec is returned 
 [x for x in gs] # causes infinite loop before applying patch
 # after applying the patch - which is just lines 171-172 in the
 # traceback below
 In [9]: gs[100]
 ----------------------------------------------------------
 IndexError Traceback (most recent call last)
 
 ./matplotlib/<ipython console> in <module>()
 
 ./matplotlib/gridspec.pyc
 in __getitem__(self, key)
 170 key += total
 171 if key >= total or key < 0:
 --> 172 raise IndexError("index out of range")
 173 num1, num2 = key, None
 174 
 
 IndexError: index out of range
 
 In [10]: [x for x in gs]
 Out[10]: 
 
 [<matplotlib.gridspec.SubplotSpec object at 0x9b7edcc>,
 <matplotlib.gridspec.SubplotSpec object at 0x9b8834c>]
I'm also including a patch for the gridspec docs which create a
grid-of-grids using gridspec in a colorful manner. Note that
there, I explicitly create indexes in the right range, like so:
 outer_grid = GridSpec(4, 4)
 for i in xrange(16):
 inner_grid = GridSpecFromSubplotSpec(3, 3, subplot_spec=outer_grid[i])
 for j in xrange(9):
 ax = plt.Subplot(f, inner_grid[j])
 ...
because before applying the getitem patch described above, one
*can't* currently iterate over the spec itself like this:
 outer_grid = GridSpec(4, 4)
 for cell in outer_grid:
 inner_grid = GridSpecFromSubplotSpec(3, 3, subplot_spec=cell)
 for subcell in inner_grid:
 ax = plt.Subplot(f, subcell)
 ...
The doc patch also fixes the currently broken .. _gridspec-guide:
anchor name which can be seen peeking out at the top of:
http://matplotlib.sourceforge.net/users/gridspec.html
because there was previously a misplaced leading \ on line 1 of
doc/users/gridspec.rst
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7