matplotlib-devel Mailing List for matplotlib (Page 5)

On Mon, Oct 20, 2008 at 9:01 AM, David Huard <dav...@gm...> wrote:
> I would oppose any change to histogram calling convention that does not
> fix a critical bug. I agree that using a built-in name as an argument is
> a bug, but I believe it is the lesser evil compared to asking users to
> change their code
> again.
I think in this case we have to change it, but we can do it gently.
Ie, for a release cycle, if we detect "range" in the kwarg case, we'll
set the correct kwarg, eg "binrange", issue a warning, but not raise
an error. That way users can fairly easily change their code w/o
breakage. Whoever does the deprecation should note the date and
version of the deprecation warning, so we will know when enough time
and releases have passed to remove range entirely.
JDH

On Sat, Oct 18, 2008 at 3:07 PM, Eric Firing <ef...@ha...> wrote:
> Manuel Metz wrote:
>> Please see the end of the mail for the important point !!!
>
> Thank you--I see you are way ahead of me on this. See comments below.
>>
>> Eric Firing wrote:
>>> Manuel,
>>>
>>> Although it doesn't hurt, I don't think it is worthwhile changing range
>>> to xrange. From the 2.5 docs:
>> [...snip...]
>>> Note "minimal" advantage. xrange was intended for special-case use, not
>>> general use.
>>
>> Eric,
>>
>> yes, I absolutely agree with you that this is only a small (minimal)
>> advantage, probably not worth to worry about. Nevertheless ...
>>
>>> And from Python 3.0, http://docs.python.org/dev/3.0/whatsnew/3.0.html
>>> xrange() renamed to range(), so range() will no longer produce a list
>>> but an iterable yielding integers when iterated over.
>>
>> Python 3.0 will use xrange() by default, but it is then named range(),
>> so from that _I_ conclude that xrange() should be used by default. You
>> can also see the difference by using 2to3:
>>
>> """
>> for i in range(10): print i
>> for i in xrange(10): print i
>> """
>>
>> gets converted to:
>>
>> """
>> for i in range(10): print i
>> for i in range(10): print i
>> """
>>
>> That is, because 2to3 is a clever program. But:
>>
>> """
>> a = range(10)
>> b = xrange(10)
>> for i in a: print i
>> for i in b: print i
>> """
>>
>> gets converted to
>>
>> """
>> a = list(range(10))
>> b = range(10)
>> for i in a: print(i)
>> for i in b: print(i)
>> """
>>
>> ;-)
>>
>> As you said, it's only a minimal advantage and 2to3 is a clever code!!!
>>
>
> I am glad you brought the above to my attention--it completely changes
> my point of view. It does appear that changing to xrange now, whenever
> it will work (that is, when one does not *need* a list) will make the
> transition to Python 3 more efficient and has no disadvantage with
> present code.
>
>>
>> (THE IMPORTANT POINT)
>>
>> But this brings me to another, more important point: In the axes hist()
>> method, a keyword named "range" is used that is passed to the numpy
>> histogram() function, which has the kwarg 'range'. Now, this is not a
>> problem as long as the range() builtin function is not used in the
>> hist() method. But there are a few loops in this method that use
>> xrange(), so this code will be translated to range() in py3 -- and that
>> will be a problem. A basic example with a pseudo-code:
>>
The histogram function contains the code for the old behaviour and the
new behaviour side
by side. Now only the old behaviour uses xrange, while the new
behaviour uses numpy's arange.
The old behaviour will be gone altogether in release 1.4.
>> """
>> def foo(x, range=(1,10)):
>> print range
>> for i in xrange(x): print i
>> foo(10)
>> """
>>
>> with 2to3 -->
>>
>> """
>> def foo(x, range=(1,10)):
>> print(range)
>> for i in range(x): print(i)
>> foo(10)
>> """
>> which then fails.
>>
>> One solution would be to use a different keyword argument, maybe
>> "binrange" instead of "range" and to throw a deprecated warning for the
>> old keyword ???
>>
>
> Yes, I think the use of any builtin as a kwarg is a bug that should be
> squashed via a new kwarg with a deprecation. Similarly, use of any
> builtin as in internal variable should be considered a latent bug and fixed.
>
> Unfortunately, in this case, the badly-named kwarg is in numpy.histogram
> as well. The best thing would be to try to get the same change made in
> numpy so that mpl hist and numpy.histogram kwargs would stay in sync.
>
> To make matters worse, histogram has evolved in such a way that its
> kwargs are a confusing mess. It is too bad that when the "new" syntax
> was developed, the "range" kwarg was not changed at the same time.
Indeed.
> I don't know whether any more changes would be accepted now.
I would oppose any change to histogram calling convention that does not
fix a critical bug. I agree that using a built-in name as an argument is
a bug, but I believe it is the lesser evil compared to asking users to
change their code
again.
I've added a note in numpy ticket 797 suggesting that a py3k
compatible numpy version
should have the old behaviour removed to avoid the name clash.
Thanks for bringing this up,
Regards,
David
> If there is to be a new kwarg, I think I would call it "cliprange",
> since it is essentially used to clip the input--unless "new" is not
> True. It is not really a "bin range", because it can be set
> independently of the bins. (I have not traced the code; I am basing my
> statement on the docstring, so I could be wrong about what the code
> actually does.)
>
> Eric
>
>> Manuel
>>
>>> This implies to me that range is the preferred form, and xrange is
>>> intended to go away.
>>>
>>> Eric
>>>
>> [...snip...]
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Mon, Oct 20, 2008 at 7:51 AM, Lee Kamentsky <le...@br...> wrote:
> Hi all,
> I've submitted a patch to
> matplotlib/lib/matplotlib/backends/backend_wx.py on the bug tracker
> (http://sourceforge.net/tracker2/?func=detail&aid=2166139&group_id=80706&atid=560722
> ). I'd appreciate feedback on it and am looking forward to the
> functionality making it into an upcoming release.
>
> Briefly, the patch fixes a bug when running under Windows and implements
> draw_image for the backend.
We'll be happy to take a look at this, but since we are trying to
figure out whether we should keep backend_ex at all, could you tell us
why you prefer or require backend wx over wxagg?
Thanks,
JDH

Hi all,
I've submitted a patch to 
matplotlib/lib/matplotlib/backends/backend_wx.py on the bug tracker 
(http://sourceforge.net/tracker2/?func=detail&aid=2166139&group_id=80706&atid=560722 
). I'd appreciate feedback on it and am looking forward to the 
functionality making it into an upcoming release.
Briefly, the patch fixes a bug when running under Windows and implements 
draw_image for the backend.
Thanks,
Lee Kamentsky

The current patch looks good to me... it satisfies all the use cases I
had in mind, and I can't think of much else that would be wanted.
Thanks!
I also very much like the idea of the "sizebar," although that's
probably a substantially larger job to implement. I may look into it
though, time permitting...
On Sat, Oct 18, 2008 at 7:04 PM, Jae-Joon Lee <lee...@gm...> wrote:
>> To help clarify the original purpose of "update_from": I wrote this
>> method when writing the original legend implementation so the legend
>> proxy objects could easily copy their style attributes from the
>> underlying objects they were a proxy for (so not every property is
>> copied, eg the xdata for line objects is not copied). So the
>> operating question should be: what properties do I need to copy to
>> make the legend representation of the object. While you are in
>> there, perhaps you could clarify this in the docstrings of the
>> update_from method.
>
> Thanks for clarifying this, John.
>
> Manuel,
> The patch looks good to me. We may submit the patch (I hope Erik is
> okay with the current patch) and it would be great if you handle the
> submission.
>
> -JJ
>
>
>
>
>
> On Fri, Oct 17, 2008 at 9:45 PM, Manuel Metz <mm...@as...> wrote:
>> Jae-Joon Lee wrote:
>>> Thanks Manuel.
>>>
>>> Yes, we need rotation value and etc, but my point is, do we need to
>>> update it within the update_from() method? Although my preference is
>>> not to do it, it may not matter much as far as we state what this
>>> method does clearly in the doc.
>>
>> Okay, it's probably better to create the object correctly (numsides ...)
>> instead of copying the properties (see also JDHs mail !)
>>
>>> And, in your patch, I don't think updating the numsides value has any
>>> effect as it does not recreate the paths.
>>>
>>> I'm attaching the revised patch. In this patch, update_from() only
>>> update gc-related properties. And numsides, size, and rotations are
>>> given during the object creation time.
>>
>> Yes, this looks better. But creating handle_sizes is a little bit too
>> much effort. This is done internally. It will do passing a sizes list,
>> that may or may not be shorter/longer than numpoints (see revised patch).
>>
>> I also changed the way the yoffsets are updated in _update_positions().
>>
>> One additional thing I have in mind (for a later time) is a "sizesbar"
>> similar to a colorbar where you can read off values corresponding to
>> marker sizes...
>>
>> Cheers,
>> Manuel
>>
>>> Erik,
>>> I see your points. My main concern is that the yoffsets makes the
>>> results a bit funny when numpoints is 2. The attached patch has a
>>> varying sizes of [0.5*(max+min), max, min]. The yoffsets are only
>>> introduced when numpints > 2 and you can also provide it as an
>>> optional argument.
>>>
>>> Regards,
>>>
>>> -JJ
>>>
>>>
>>> On Thu, Oct 16, 2008 at 8:43 PM, Manuel Metz <mm...@as...> wrote:
>>>> Manuel Metz wrote:
>>>>> Jae-Joon Lee wrote:
>>>>>> Hi Manuel,
>>>>>>
>>>>>> I think it is a good to introduce the update_from method in Collections.
>>>>>> But, I'm not sure if it is a good idea to also update sizes, paths and
>>>>>> rotation (in RegularPolyCoolection). My impression is that update_from
>>>>>> method is to update gc related attributes. For comparison,
>>>>>> Patch.update_from() does not update the path.
>>>>> That's exactly the point why I wasn't fully happy with the patch. The
>>>>> path is generated by the _path_generator, so instead of copying the path
>>>>> it seems to be better to create an instance of the corresponding class
>>>>> (e.g. the StarPolygonCollection class, as suggested before).
>>>>>
>>>>> One should update the rotation attribute (!!); it's only one number. A
>>>>> '+' marker, for example, has rotation = 0, whereas a 'x' marker has
>>>>> rotation=pi/4. That's the only difference between those two !
>>>>>
>>>>>> Also, is it okay to update properties without checking its length?. It
>>>>>> does not seem to cause any problems though.
>>>>> It's in principal not a problem to copy the sizes attribute without
>>>>> checking the length. If it's shorter the the number of items the sizes
>>>>> are repeated; if it's longer it gets truncated.
>>>>>
>>>>> mm
>>>>>
>>>>>> I guess It would better to use xdata_markers than xdata in the
>>>>>> get_handle() method. The difference is when numpoints==1. Using xdata
>>>>>> gives two marker points.
>>>>>>
>>>>>> I was actually about to to commit my patch. I'll try to account your
>>>>>> changes and post my version of patch later today.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> -JJ
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <mm...@as...> wrote:
>>>>>>> hmm
>>>>>>>
>>>>>>> -------- Original Message --------
>>>>>>> Jae-Joon Lee wrote:
>>>>>>>>> - the parameter numpoints should be used (it's ignored right now)
>>>>>>>>>
>>>>>>>> Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
>>>>>>>>
>>>>>>>>
>>>>>>>>> - Some private variables are accessed and a new RegularPolycollection is
>>>>>>>>> created (does this work eg. with a StarPolygonCollection? I haven't
>>>>>>>>> checked, but I don't think so !). Instead of creating a new
>>>>>>>>> RegularPolyCollection it might be more useful to make a copy of the
>>>>>>>>> existing object... I was thinking about a update_from() method for the
>>>>>>>>> Collection class(es) similar to update_from() for lines.
>>>>>>>>>
>>>>>>>> By changing "RegularPolyCoolection" to "type(handles)", it works for
>>>>>>>> StarPolygonCollection.
>>>>>>>>
>>>>>>>> In Erik's current implementation, the markers in the legend have
>>>>>>>> varying colors, sizes, and y offsets.
>>>>>>>> The color variation seems fine. But do we need to vary the sizes and
>>>>>>>> y-offsets? My inclination is to use a fixed size (median?) and a fixed
>>>>>>>> y offset. How does Erik and others think?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> -JJ
>>>>>>> Attached is my current version of the patch. I've moved all of the
>>>>>>> properties-copying stuff to collections, which makes the changes
>>>>>>> legend.py more clearer (but I'm not fully happy with the patch and
>>>>>>> haven't commit anything yet)
>>>>>>>
>>>>>>> mm
>>>>>>>
>>>> Hi Jae-Joon,
>>>> so here is my revised version of the patch. What do you think ?
>>>>
>>>> Manuel
>>>>
>>>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

John Hunter wrote:
> On Sat, Oct 18, 2008 at 8:34 AM, Manuel Metz <mm...@as...> wrote:
>> With a clear checkout building the docs fails:
>>
>> [...]
>> Sphinx v0.4.2, building html
>> trying to load pickled env... not found
>> building [html]: targets for 348 source files that are out of date
>> updating environment: 348 added, 0 changed, 0 removed
>> reading... api/afm_api api/artist_api Exception occurred:
>> File "/usr/lib/python2.5/shutil.py", line 51, in copyfile
>> fsrc = open(src, 'rb')
>> IOError: [Errno 2] No such file or directory:
>> '../mpl_examples/pylab_examples/findobj_demo.py'
>> The full traceback has been saved in /tmp/sphinx-err-X12gbJ.log, if you
>> want to report the issue to the author.
>> Please also report this if it was a user error, so that a better error
>> message can be provided next time.
>> Send reports to sph...@go.... Thanks!
>> Building HTML failed.
> 
> I was gettin a similar error on one platform, but not on another,
> though I was using clean svn dirs for the build in each one. I
> guessed it might be related to sphinx version I was using for the
> build, and when I upgraded sphinx to 0.5 (svn HEAD actually) on the
> broken platform I got a working doc build. Give it a try,
> 
> JDH
Ah okay - thanks John. It was working before with sphinx 0.4.2 (on
Ubuntu 8.10b). Now, after upgrading to sphinx 0.5 trunk it works again.
mm

On Sat, Oct 18, 2008 at 8:34 AM, Manuel Metz <mm...@as...> wrote:
> With a clear checkout building the docs fails:
>
> [...]
> Sphinx v0.4.2, building html
> trying to load pickled env... not found
> building [html]: targets for 348 source files that are out of date
> updating environment: 348 added, 0 changed, 0 removed
> reading... api/afm_api api/artist_api Exception occurred:
> File "/usr/lib/python2.5/shutil.py", line 51, in copyfile
> fsrc = open(src, 'rb')
> IOError: [Errno 2] No such file or directory:
> '../mpl_examples/pylab_examples/findobj_demo.py'
> The full traceback has been saved in /tmp/sphinx-err-X12gbJ.log, if you
> want to report the issue to the author.
> Please also report this if it was a user error, so that a better error
> message can be provided next time.
> Send reports to sph...@go.... Thanks!
> Building HTML failed.
I was gettin a similar error on one platform, but not on another,
though I was using clean svn dirs for the build in each one. I
guessed it might be related to sphinx version I was using for the
build, and when I upgraded sphinx to 0.5 (svn HEAD actually) on the
broken platform I got a working doc build. Give it a try,
JDH

> To help clarify the original purpose of "update_from": I wrote this
> method when writing the original legend implementation so the legend
> proxy objects could easily copy their style attributes from the
> underlying objects they were a proxy for (so not every property is
> copied, eg the xdata for line objects is not copied). So the
> operating question should be: what properties do I need to copy to
> make the legend representation of the object. While you are in
> there, perhaps you could clarify this in the docstrings of the
> update_from method.
Thanks for clarifying this, John.
Manuel,
The patch looks good to me. We may submit the patch (I hope Erik is
okay with the current patch) and it would be great if you handle the
submission.
-JJ
On Fri, Oct 17, 2008 at 9:45 PM, Manuel Metz <mm...@as...> wrote:
> Jae-Joon Lee wrote:
>> Thanks Manuel.
>>
>> Yes, we need rotation value and etc, but my point is, do we need to
>> update it within the update_from() method? Although my preference is
>> not to do it, it may not matter much as far as we state what this
>> method does clearly in the doc.
>
> Okay, it's probably better to create the object correctly (numsides ...)
> instead of copying the properties (see also JDHs mail !)
>
>> And, in your patch, I don't think updating the numsides value has any
>> effect as it does not recreate the paths.
>>
>> I'm attaching the revised patch. In this patch, update_from() only
>> update gc-related properties. And numsides, size, and rotations are
>> given during the object creation time.
>
> Yes, this looks better. But creating handle_sizes is a little bit too
> much effort. This is done internally. It will do passing a sizes list,
> that may or may not be shorter/longer than numpoints (see revised patch).
>
> I also changed the way the yoffsets are updated in _update_positions().
>
> One additional thing I have in mind (for a later time) is a "sizesbar"
> similar to a colorbar where you can read off values corresponding to
> marker sizes...
>
> Cheers,
> Manuel
>
>> Erik,
>> I see your points. My main concern is that the yoffsets makes the
>> results a bit funny when numpoints is 2. The attached patch has a
>> varying sizes of [0.5*(max+min), max, min]. The yoffsets are only
>> introduced when numpints > 2 and you can also provide it as an
>> optional argument.
>>
>> Regards,
>>
>> -JJ
>>
>>
>> On Thu, Oct 16, 2008 at 8:43 PM, Manuel Metz <mm...@as...> wrote:
>>> Manuel Metz wrote:
>>>> Jae-Joon Lee wrote:
>>>>> Hi Manuel,
>>>>>
>>>>> I think it is a good to introduce the update_from method in Collections.
>>>>> But, I'm not sure if it is a good idea to also update sizes, paths and
>>>>> rotation (in RegularPolyCoolection). My impression is that update_from
>>>>> method is to update gc related attributes. For comparison,
>>>>> Patch.update_from() does not update the path.
>>>> That's exactly the point why I wasn't fully happy with the patch. The
>>>> path is generated by the _path_generator, so instead of copying the path
>>>> it seems to be better to create an instance of the corresponding class
>>>> (e.g. the StarPolygonCollection class, as suggested before).
>>>>
>>>> One should update the rotation attribute (!!); it's only one number. A
>>>> '+' marker, for example, has rotation = 0, whereas a 'x' marker has
>>>> rotation=pi/4. That's the only difference between those two !
>>>>
>>>>> Also, is it okay to update properties without checking its length?. It
>>>>> does not seem to cause any problems though.
>>>> It's in principal not a problem to copy the sizes attribute without
>>>> checking the length. If it's shorter the the number of items the sizes
>>>> are repeated; if it's longer it gets truncated.
>>>>
>>>> mm
>>>>
>>>>> I guess It would better to use xdata_markers than xdata in the
>>>>> get_handle() method. The difference is when numpoints==1. Using xdata
>>>>> gives two marker points.
>>>>>
>>>>> I was actually about to to commit my patch. I'll try to account your
>>>>> changes and post my version of patch later today.
>>>>>
>>>>> Regards,
>>>>>
>>>>> -JJ
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <mm...@as...> wrote:
>>>>>> hmm
>>>>>>
>>>>>> -------- Original Message --------
>>>>>> Jae-Joon Lee wrote:
>>>>>>>> - the parameter numpoints should be used (it's ignored right now)
>>>>>>>>
>>>>>>> Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
>>>>>>>
>>>>>>>
>>>>>>>> - Some private variables are accessed and a new RegularPolycollection is
>>>>>>>> created (does this work eg. with a StarPolygonCollection? I haven't
>>>>>>>> checked, but I don't think so !). Instead of creating a new
>>>>>>>> RegularPolyCollection it might be more useful to make a copy of the
>>>>>>>> existing object... I was thinking about a update_from() method for the
>>>>>>>> Collection class(es) similar to update_from() for lines.
>>>>>>>>
>>>>>>> By changing "RegularPolyCoolection" to "type(handles)", it works for
>>>>>>> StarPolygonCollection.
>>>>>>>
>>>>>>> In Erik's current implementation, the markers in the legend have
>>>>>>> varying colors, sizes, and y offsets.
>>>>>>> The color variation seems fine. But do we need to vary the sizes and
>>>>>>> y-offsets? My inclination is to use a fixed size (median?) and a fixed
>>>>>>> y offset. How does Erik and others think?
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> -JJ
>>>>>> Attached is my current version of the patch. I've moved all of the
>>>>>> properties-copying stuff to collections, which makes the changes
>>>>>> legend.py more clearer (but I'm not fully happy with the patch and
>>>>>> haven't commit anything yet)
>>>>>>
>>>>>> mm
>>>>>>
>>> Hi Jae-Joon,
>>> so here is my revised version of the patch. What do you think ?
>>>
>>> Manuel
>>>
>>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Tony S Yu wrote:
> I was using pcolor with very large numbers and a small vrange (vmax - 
> vmin), and ran into a float to integer conversion problem. Large numbers 
> get converted to *negative* integers by astype (see numpy thread 
> <http://projects.scipy.org/pipermail/numpy-discussion/2008-October/038159.html>) in 
> colors.Colormap.__call__.
> 
> I'm not sure if this is even worth fixing since almost no one would run 
> into this problem (unless you were doing something stupid, like trying 
> to use pcolor as a 2D zero finder :). For the error to occur, you have 
> to set vmin/vmax values (otherwise, the data is properly normalized 
> before converting to integers), and your data has to greatly exceed 
> these limits.
Tony,
Thank you.
I committed the change; it looks like the cost of the extra clip is 
negligible, and it is nice to make the behavior correct even under 
extreme conditions.
Eric
> 
> Cheers,
> -Tony
> 
> 
> ------------------------------------------------------------------------
> 
> 
> Example of the problem:
> #~~~~~~~~~~~~~
> import matplotlib.pyplot as plt
> import numpy as np
> 
> cmap = plt.cm.gray
> cmap.set_over('r', 1.0)
> cmap.set_under('g', 1.0)
> cmap.set_bad('b', 1.0)
> 
> eps = 1E-8
> 
> A = np.arange(100).reshape(10, 10)
> plt.pcolor(A, vmin=50, vmax=50+eps, cmap=cmap)
> # the plot should be about half red and half green (plus a black square)
> # without patch, some of the red squares are filled green
> plt.show()
> #~~~~~~~~~~~~~
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Manuel Metz wrote:
> Please see the end of the mail for the important point !!!
Thank you--I see you are way ahead of me on this. See comments below.
> 
> Eric Firing wrote:
>> Manuel,
>>
>> Although it doesn't hurt, I don't think it is worthwhile changing range 
>> to xrange. From the 2.5 docs:
> [...snip...]
>> Note "minimal" advantage. xrange was intended for special-case use, not 
>> general use.
> 
> Eric,
> 
> yes, I absolutely agree with you that this is only a small (minimal)
> advantage, probably not worth to worry about. Nevertheless ...
> 
>> And from Python 3.0, http://docs.python.org/dev/3.0/whatsnew/3.0.html
>> xrange() renamed to range(), so range() will no longer produce a list 
>> but an iterable yielding integers when iterated over.
> 
> Python 3.0 will use xrange() by default, but it is then named range(),
> so from that _I_ conclude that xrange() should be used by default. You
> can also see the difference by using 2to3:
> 
> """
> for i in range(10): print i
> for i in xrange(10): print i
> """
> 
> gets converted to:
> 
> """
> for i in range(10): print i
> for i in range(10): print i
> """
> 
> That is, because 2to3 is a clever program. But:
> 
> """
> a = range(10)
> b = xrange(10)
> for i in a: print i
> for i in b: print i
> """
> 
> gets converted to
> 
> """
> a = list(range(10))
> b = range(10)
> for i in a: print(i)
> for i in b: print(i)
> """
> 
> ;-)
> 
> As you said, it's only a minimal advantage and 2to3 is a clever code!!!
> 
I am glad you brought the above to my attention--it completely changes 
my point of view. It does appear that changing to xrange now, whenever 
it will work (that is, when one does not *need* a list) will make the 
transition to Python 3 more efficient and has no disadvantage with 
present code.
> 
> (THE IMPORTANT POINT)
> 
> But this brings me to another, more important point: In the axes hist()
> method, a keyword named "range" is used that is passed to the numpy
> histogram() function, which has the kwarg 'range'. Now, this is not a
> problem as long as the range() builtin function is not used in the
> hist() method. But there are a few loops in this method that use
> xrange(), so this code will be translated to range() in py3 -- and that
> will be a problem. A basic example with a pseudo-code:
> 
> """
> def foo(x, range=(1,10)):
> print range
> for i in xrange(x): print i
> foo(10)
> """
> 
> with 2to3 -->
> 
> """
> def foo(x, range=(1,10)):
> print(range)
> for i in range(x): print(i)
> foo(10)
> """
> which then fails.
> 
> One solution would be to use a different keyword argument, maybe
> "binrange" instead of "range" and to throw a deprecated warning for the
> old keyword ???
> 
Yes, I think the use of any builtin as a kwarg is a bug that should be 
squashed via a new kwarg with a deprecation. Similarly, use of any 
builtin as in internal variable should be considered a latent bug and fixed.
Unfortunately, in this case, the badly-named kwarg is in numpy.histogram 
as well. The best thing would be to try to get the same change made in 
numpy so that mpl hist and numpy.histogram kwargs would stay in sync.
To make matters worse, histogram has evolved in such a way that its 
kwargs are a confusing mess. It is too bad that when the "new" syntax 
was developed, the "range" kwarg was not changed at the same time. I 
don't know whether any more changes would be accepted now.
If there is to be a new kwarg, I think I would call it "cliprange", 
since it is essentially used to clip the input--unless "new" is not 
True. It is not really a "bin range", because it can be set 
independently of the bins. (I have not traced the code; I am basing my 
statement on the docstring, so I could be wrong about what the code 
actually does.)
Eric
> Manuel
> 
>> This implies to me that range is the preferred form, and xrange is 
>> intended to go away.
>>
>> Eric
>>
> [...snip...]
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Sorry, I attached the wrong file:
On Oct 18, 2008, at 11:23 AM, Tony S Yu wrote:
> I was using pcolor with very large numbers and a small vrange (vmax 
> - vmin), and ran into a float to integer conversion problem. Large 
> numbers get converted to *negative* integers by astype (see numpy 
> thread) in colors.Colormap.__call__.
>
> I'm not sure if this is even worth fixing since almost no one would 
> run into this problem (unless you were doing something stupid, like 
> trying to use pcolor as a 2D zero finder :). For the error to occur, 
> you have to set vmin/vmax values (otherwise, the data is properly 
> normalized before converting to integers), and your data has to 
> greatly exceed these limits.
>
> Cheers,
> -Tony
> <clip_vs_putmask.py>
>
> Example of the problem:
> #~~~~~~~~~~~~~
> import matplotlib.pyplot as plt
> import numpy as np
>
> cmap = plt.cm.gray
> cmap.set_over('r', 1.0)
> cmap.set_under('g', 1.0)
> cmap.set_bad('b', 1.0)
>
> eps = 1E-8
>
> A = np.arange(100).reshape(10, 10)
> plt.pcolor(A, vmin=50, vmax=50+eps, cmap=cmap)
> # the plot should be about half red and half green (plus a black 
> square)
> # without patch, some of the red squares are filled green
> plt.show()
> #~~~~~~~~~~~~~
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's 
> challenge
> Build the coolest Linux based applications with Moblin SDK & win 
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in 
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I was using pcolor with very large numbers and a small vrange (vmax - 
vmin), and ran into a float to integer conversion problem. Large 
numbers get converted to *negative* integers by astype (see numpy 
thread) in colors.Colormap.__call__.
I'm not sure if this is even worth fixing since almost no one would 
run into this problem (unless you were doing something stupid, like 
trying to use pcolor as a 2D zero finder :). For the error to occur, 
you have to set vmin/vmax values (otherwise, the data is properly 
normalized before converting to integers), and your data has to 
greatly exceed these limits.
Cheers,
-Tony
Example of the problem:
#~~~~~~~~~~~~~
import matplotlib.pyplot as plt
import numpy as np
cmap = plt.cm.gray
cmap.set_over('r', 1.0)
cmap.set_under('g', 1.0)
cmap.set_bad('b', 1.0)
eps = 1E-8
A = np.arange(100).reshape(10, 10)
plt.pcolor(A, vmin=50, vmax=50+eps, cmap=cmap)
# the plot should be about half red and half green (plus a black square)
# without patch, some of the red squares are filled green
plt.show()
#~~~~~~~~~~~~~

With a clear checkout building the docs fails:
[...]
Sphinx v0.4.2, building html
trying to load pickled env... not found
building [html]: targets for 348 source files that are out of date
updating environment: 348 added, 0 changed, 0 removed
reading... api/afm_api api/artist_api Exception occurred:
 File "/usr/lib/python2.5/shutil.py", line 51, in copyfile
 fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory:
'../mpl_examples/pylab_examples/findobj_demo.py'
The full traceback has been saved in /tmp/sphinx-err-X12gbJ.log, if you
want to report the issue to the author.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Send reports to sph...@go.... Thanks!
Building HTML failed.

Please see the end of the mail for the important point !!!
Eric Firing wrote:
> Manuel,
> 
> Although it doesn't hurt, I don't think it is worthwhile changing range 
> to xrange. From the 2.5 docs:
[...snip...]
> Note "minimal" advantage. xrange was intended for special-case use, not 
> general use.
Eric,
yes, I absolutely agree with you that this is only a small (minimal)
advantage, probably not worth to worry about. Nevertheless ...
> And from Python 3.0, http://docs.python.org/dev/3.0/whatsnew/3.0.html
> xrange() renamed to range(), so range() will no longer produce a list 
> but an iterable yielding integers when iterated over.
Python 3.0 will use xrange() by default, but it is then named range(),
so from that _I_ conclude that xrange() should be used by default. You
can also see the difference by using 2to3:
"""
for i in range(10): print i
for i in xrange(10): print i
"""
gets converted to:
"""
for i in range(10): print i
for i in range(10): print i
"""
That is, because 2to3 is a clever program. But:
"""
a = range(10)
b = xrange(10)
for i in a: print i
for i in b: print i
"""
gets converted to
"""
a = list(range(10))
b = range(10)
for i in a: print(i)
for i in b: print(i)
"""
;-)
As you said, it's only a minimal advantage and 2to3 is a clever code!!!
(THE IMPORTANT POINT)
But this brings me to another, more important point: In the axes hist()
method, a keyword named "range" is used that is passed to the numpy
histogram() function, which has the kwarg 'range'. Now, this is not a
problem as long as the range() builtin function is not used in the
hist() method. But there are a few loops in this method that use
xrange(), so this code will be translated to range() in py3 -- and that
will be a problem. A basic example with a pseudo-code:
"""
def foo(x, range=(1,10)):
 print range
 for i in xrange(x): print i
foo(10)
"""
with 2to3 -->
"""
def foo(x, range=(1,10)):
 print(range)
 for i in range(x): print(i)
foo(10)
"""
which then fails.
One solution would be to use a different keyword argument, maybe
"binrange" instead of "range" and to throw a deprecated warning for the
old keyword ???
Manuel
> This implies to me that range is the preferred form, and xrange is 
> intended to go away.
> 
> Eric
> 
[...snip...]

On Oct 17, 2008, at 7:29 AM, John Hunter wrote:
> Hey Tony,
>
> Thanks for the patch, applied to svn r6232. For future patches, could
> you send a "svn diff" from the matplotlib directory containing
> setup.py. That way I don't have to think too hard about the patch
> level, what kind of patch it is etc
Doh, I think you mentioned this to me before. Sorry about that.
> Thanks again,
> JDH

On Wed, Oct 15, 2008 at 2:57 PM, Manuel Metz <mm...@as...> wrote:
> I found a few typos in artists.rst. Added a patch (don't want to commit
> it, because I'm not actively working on the docs)
>
> The first sentence of the section "Object containers" also needs to be
> fixed (or I don't understand it):
> "Now that we know how to inspect set the properties of a given object
> we want to configure, we need to now how to get at that object."
>
> "inspect" or "set" ???
"inspect and set"
Thanks for the patch -- I just applied it to svn r6234
JDH

Jae-Joon Lee wrote:
> Thanks Manuel.
> 
> Yes, we need rotation value and etc, but my point is, do we need to
> update it within the update_from() method? Although my preference is
> not to do it, it may not matter much as far as we state what this
> method does clearly in the doc.
Okay, it's probably better to create the object correctly (numsides ...)
instead of copying the properties (see also JDHs mail !)
> And, in your patch, I don't think updating the numsides value has any
> effect as it does not recreate the paths.
> 
> I'm attaching the revised patch. In this patch, update_from() only
> update gc-related properties. And numsides, size, and rotations are
> given during the object creation time.
Yes, this looks better. But creating handle_sizes is a little bit too
much effort. This is done internally. It will do passing a sizes list,
that may or may not be shorter/longer than numpoints (see revised patch).
I also changed the way the yoffsets are updated in _update_positions().
One additional thing I have in mind (for a later time) is a "sizesbar"
similar to a colorbar where you can read off values corresponding to
marker sizes...
Cheers,
 Manuel
> Erik,
> I see your points. My main concern is that the yoffsets makes the
> results a bit funny when numpoints is 2. The attached patch has a
> varying sizes of [0.5*(max+min), max, min]. The yoffsets are only
> introduced when numpints > 2 and you can also provide it as an
> optional argument.
> 
> Regards,
> 
> -JJ
> 
> 
> On Thu, Oct 16, 2008 at 8:43 PM, Manuel Metz <mm...@as...> wrote:
>> Manuel Metz wrote:
>>> Jae-Joon Lee wrote:
>>>> Hi Manuel,
>>>>
>>>> I think it is a good to introduce the update_from method in Collections.
>>>> But, I'm not sure if it is a good idea to also update sizes, paths and
>>>> rotation (in RegularPolyCoolection). My impression is that update_from
>>>> method is to update gc related attributes. For comparison,
>>>> Patch.update_from() does not update the path.
>>> That's exactly the point why I wasn't fully happy with the patch. The
>>> path is generated by the _path_generator, so instead of copying the path
>>> it seems to be better to create an instance of the corresponding class
>>> (e.g. the StarPolygonCollection class, as suggested before).
>>>
>>> One should update the rotation attribute (!!); it's only one number. A
>>> '+' marker, for example, has rotation = 0, whereas a 'x' marker has
>>> rotation=pi/4. That's the only difference between those two !
>>>
>>>> Also, is it okay to update properties without checking its length?. It
>>>> does not seem to cause any problems though.
>>> It's in principal not a problem to copy the sizes attribute without
>>> checking the length. If it's shorter the the number of items the sizes
>>> are repeated; if it's longer it gets truncated.
>>>
>>> mm
>>>
>>>> I guess It would better to use xdata_markers than xdata in the
>>>> get_handle() method. The difference is when numpoints==1. Using xdata
>>>> gives two marker points.
>>>>
>>>> I was actually about to to commit my patch. I'll try to account your
>>>> changes and post my version of patch later today.
>>>>
>>>> Regards,
>>>>
>>>> -JJ
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <mm...@as...> wrote:
>>>>> hmm
>>>>>
>>>>> -------- Original Message --------
>>>>> Jae-Joon Lee wrote:
>>>>>>> - the parameter numpoints should be used (it's ignored right now)
>>>>>>>
>>>>>> Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
>>>>>>
>>>>>>
>>>>>>> - Some private variables are accessed and a new RegularPolycollection is
>>>>>>> created (does this work eg. with a StarPolygonCollection? I haven't
>>>>>>> checked, but I don't think so !). Instead of creating a new
>>>>>>> RegularPolyCollection it might be more useful to make a copy of the
>>>>>>> existing object... I was thinking about a update_from() method for the
>>>>>>> Collection class(es) similar to update_from() for lines.
>>>>>>>
>>>>>> By changing "RegularPolyCoolection" to "type(handles)", it works for
>>>>>> StarPolygonCollection.
>>>>>>
>>>>>> In Erik's current implementation, the markers in the legend have
>>>>>> varying colors, sizes, and y offsets.
>>>>>> The color variation seems fine. But do we need to vary the sizes and
>>>>>> y-offsets? My inclination is to use a fixed size (median?) and a fixed
>>>>>> y offset. How does Erik and others think?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> -JJ
>>>>> Attached is my current version of the patch. I've moved all of the
>>>>> properties-copying stuff to collections, which makes the changes
>>>>> legend.py more clearer (but I'm not fully happy with the patch and
>>>>> haven't commit anything yet)
>>>>>
>>>>> mm
>>>>>
>> Hi Jae-Joon,
>> so here is my revised version of the patch. What do you think ?
>>
>> Manuel
>>
>>

On Thu, Oct 16, 2008 at 9:10 PM, Tony S Yu <to...@mi...> wrote:
> I noticed that one of the animation examples is missing some import
> statements. Also, the diff below includes a small change to the shebang line
> of another example.
Hey Tony,
Thanks for the patch, applied to svn r6232. For future patches, could
you send a "svn diff" from the matplotlib directory containing
setup.py. That way I don't have to think too hard about the patch
level, what kind of patch it is etc
 > cd ~/path/to/mpl/src
 > svn diff > mypatch.diff
Thanks again,
JDH

On Thu, Oct 16, 2008 at 9:57 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Thanks Manuel.
>
> Yes, we need rotation value and etc, but my point is, do we need to
> update it within the update_from() method? Although my preference is
> not to do it, it may not matter much as far as we state what this
> method does clearly in the doc.
To help clarify the original purpose of "update_from": I wrote this
method when writing the original legend implementation so the legend
proxy objects could easily copy their style attributes from the
underlying objects they were a proxy for (so not every property is
copied, eg the xdata for line objects is not copied). So the
operating question should be: what properties do I need to copy to
make the legend representation of the object. While you are in
there, perhaps you could clarify this in the docstrings of the
update_from method.
Hope this helps,
JDH

On Thu, Oct 16, 2008 at 5:10 PM, Darren Dale <dar...@co...> wrote:
> It looks great, really nice work guys. Sorry I havent been able to keep up
> with the list recently, unfortunately its unlikely to change for a while.
>
> I noticed that the PDF download link at
> http://matplotlib.sourceforge.net/contents.html is broken.
Ahh, thanks for letting me know. It's fixed now (you may need to
"refresh"). sf removed shell access to the web directory, so all the
reorg and cleanup had to be done over sftp, scp and rsync via ssh,
which was a pain, so there are probably a few things that will need to
be restored/tweaked.
JDH

On Thu, Oct 16, 2008 at 9:18 PM, Paul Ivanov <piv...@gm...> wrote:
> Hi,
>
> I'm a big fan of keyboard shortcuts, so I decided to add these guys to
> lib/matplotlib/backend_bases.py
>
> I'm not sure if this is too much, and maybe these should be configurable
> down the line, but here's my first stab at it, what do you all think?
>
> in the same order as they appear in the toolbar:
> 'h' or 'r' for Home/Reset
> left arrow or 'z' or backspace for Back
> right arrow and 'x' for Forward
> 'p' for pan axes with right, zoom with left mode toggle
> 'o' for z*o*om to rectangle mode toggle
> 's' for save
> 'z' and 'x' I borrowed from the Opera browser, very handy to for
> righties who can have their left hand on the keyboard while using the mouse.
Hi Paul,
I'm amenable to additional keys, but check out
http://matplotlib.sourceforge.net/users/navigation_toolbar.html which
details which keys are already in play. Also, with your patch, please
submit a patch against the navigation toolbar doc
doc/users/navigation_toolbar.rst . Maybe a ReST table that details all
of the key bindings?
Thanks,
JDH

Paul Ivanov schrieb:
> Hi,
>
> I'm a big fan of keyboard shortcuts, so I decided to add these guys to
> lib/matplotlib/backend_bases.py	
>
> I'm not sure if this is too much, and maybe these should be configurable
> down the line, but here's my first stab at it, what do you all think?
>
> in the same order as they appear in the toolbar:
> 'h' or 'r' for Home/Reset
> left arrow or 'z' or backspace for Back
> right arrow and 'x' for Forward
> 'p' for pan axes with right, zoom with left mode toggle
> 'o' for z*o*om to rectangle mode toggle
> 's' for save
> 
I like this idea very much. What I would like to see is panning 
associated with the space bar, like it's done in Adobe Acrobat: panning 
is only activated _while_ you press space. I think this is more 
difficult to implement. Once I had a quick look at it and abandonded 
this project, it was too complicated for me. Perhaps you can manage this?
> 'z' and 'x' I borrowed from the Opera browser, very handy to for
> righties who can have their left hand on the keyboard while using the mouse.
> 
On german keyboards y and z are exchanged. Having these keys 
configurable would be handy.
Gregor

Thanks Manuel.
Yes, we need rotation value and etc, but my point is, do we need to
update it within the update_from() method? Although my preference is
not to do it, it may not matter much as far as we state what this
method does clearly in the doc.
And, in your patch, I don't think updating the numsides value has any
effect as it does not recreate the paths.
I'm attaching the revised patch. In this patch, update_from() only
update gc-related properties. And numsides, size, and rotations are
given during the object creation time.
Erik,
I see your points. My main concern is that the yoffsets makes the
results a bit funny when numpoints is 2. The attached patch has a
varying sizes of [0.5*(max+min), max, min]. The yoffsets are only
introduced when numpints > 2 and you can also provide it as an
optional argument.
Regards,
-JJ
On Thu, Oct 16, 2008 at 8:43 PM, Manuel Metz <mm...@as...> wrote:
> Manuel Metz wrote:
>> Jae-Joon Lee wrote:
>>> Hi Manuel,
>>>
>>> I think it is a good to introduce the update_from method in Collections.
>>> But, I'm not sure if it is a good idea to also update sizes, paths and
>>> rotation (in RegularPolyCoolection). My impression is that update_from
>>> method is to update gc related attributes. For comparison,
>>> Patch.update_from() does not update the path.
>>
>> That's exactly the point why I wasn't fully happy with the patch. The
>> path is generated by the _path_generator, so instead of copying the path
>> it seems to be better to create an instance of the corresponding class
>> (e.g. the StarPolygonCollection class, as suggested before).
>>
>> One should update the rotation attribute (!!); it's only one number. A
>> '+' marker, for example, has rotation = 0, whereas a 'x' marker has
>> rotation=pi/4. That's the only difference between those two !
>>
>>> Also, is it okay to update properties without checking its length?. It
>>> does not seem to cause any problems though.
>>
>> It's in principal not a problem to copy the sizes attribute without
>> checking the length. If it's shorter the the number of items the sizes
>> are repeated; if it's longer it gets truncated.
>>
>> mm
>>
>>> I guess It would better to use xdata_markers than xdata in the
>>> get_handle() method. The difference is when numpoints==1. Using xdata
>>> gives two marker points.
>>>
>>> I was actually about to to commit my patch. I'll try to account your
>>> changes and post my version of patch later today.
>>>
>>> Regards,
>>>
>>> -JJ
>>>
>>>
>>>
>>>
>>> On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <mm...@as...> wrote:
>>>> hmm
>>>>
>>>> -------- Original Message --------
>>>> Jae-Joon Lee wrote:
>>>>>> - the parameter numpoints should be used (it's ignored right now)
>>>>>>
>>>>> Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
>>>>>
>>>>>
>>>>>> - Some private variables are accessed and a new RegularPolycollection is
>>>>>> created (does this work eg. with a StarPolygonCollection? I haven't
>>>>>> checked, but I don't think so !). Instead of creating a new
>>>>>> RegularPolyCollection it might be more useful to make a copy of the
>>>>>> existing object... I was thinking about a update_from() method for the
>>>>>> Collection class(es) similar to update_from() for lines.
>>>>>>
>>>>> By changing "RegularPolyCoolection" to "type(handles)", it works for
>>>>> StarPolygonCollection.
>>>>>
>>>>> In Erik's current implementation, the markers in the legend have
>>>>> varying colors, sizes, and y offsets.
>>>>> The color variation seems fine. But do we need to vary the sizes and
>>>>> y-offsets? My inclination is to use a fixed size (median?) and a fixed
>>>>> y offset. How does Erik and others think?
>>>>>
>>>>> Regards,
>>>>>
>>>>> -JJ
>>>> Attached is my current version of the patch. I've moved all of the
>>>> properties-copying stuff to collections, which makes the changes
>>>> legend.py more clearer (but I'm not fully happy with the patch and
>>>> haven't commit anything yet)
>>>>
>>>> mm
>>>>
>
> Hi Jae-Joon,
> so here is my revised version of the patch. What do you think ?
>
> Manuel
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hi,
I'm a big fan of keyboard shortcuts, so I decided to add these guys to
lib/matplotlib/backend_bases.py	
I'm not sure if this is too much, and maybe these should be configurable
down the line, but here's my first stab at it, what do you all think?
in the same order as they appear in the toolbar:
'h' or 'r' for Home/Reset
left arrow or 'z' or backspace for Back
right arrow and 'x' for Forward
'p' for pan axes with right, zoom with left mode toggle
'o' for z*o*om to rectangle mode toggle
's' for save
'z' and 'x' I borrowed from the Opera browser, very handy to for
righties who can have their left hand on the keyboard while using the mouse.
I decided to use 'o' for zoom to rect since it's located right next to
the 'p' for panning, and both are modes.
There was also a message on the matplotlib-users list in July that this
patch would be useful for
Subj: [Matplotlib-users] tool bar help / feature request
From: Ben Axelrod <baxelrod@co...> - 2008年07月31日 16:08
(but I don't know how to reply to that message as I was not on the the
users list at that time)
cheers,
Paul Ivanov

I noticed that one of the animation examples is missing some import 
statements. Also, the diff below includes a small change to the 
shebang line of another example.
Cheers,
-Tony