matplotlib-devel Mailing List for matplotlib

On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>
>
> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
> wrote:
>>
>> Often when I want to
>> zoom in, I want to change only (say) the upper x and y limits.
>
> I pushed a change into the svn that enables this, but in a different way
> than you suggested.
> The behavior I implemented is similar to the current behavior of the "pan"
> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
> is updated. Same for "y" key.
> I hope this is good for your needs also.
Well, it's an interesting feature, but it doesn't address the problem
I'm seeing.
What I'd like to be able to do is, say, to change only the upper x and
y limits, simply click where I want those limits to be and drag right
off the corner of the plot. This actually works, but when I do this
the drag rectangle freezes the moment my pointer leaves the axes, so
that it does not represent the area being zoomed to.
I've attached a screenshot illustrating the bug. Note where the
pointer is and where the "to be zoomed" rectangle is.
I use Linux, with the default backend, whatever that is.
Anne
> Regards,
> -JJ
>

On Sun, Mar 21, 2010 at 6:07 PM, Eric Firing <ef...@ha...> wrote:
> I think your version would need an additional try/except or conditional,
> because a Figure doesn't necessarily have a canvas assigned to it, and a
> canvas doesn't necessarily have a manager. Granted, the problem would arise
> only under odd circumstances involving a mixture of pyplot and OO
> styles--and maybe there is actually something that would prevent the problem
> from arising at all--but I would want to be sure the problem either was
> handled, or could not arise. So, I think my version ends up being simpler,
> safer, and easier to understand--at least for me.
>
I see. Thanks!
-JJ

On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald
<aar...@ph...>wrote:
> Often when I want to
> zoom in, I want to change only (say) the upper x and y limits.
>
I pushed a change into the svn that enables this, but in a different way
than you suggested.
The behavior I implemented is similar to the current behavior of the "pan"
mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
is updated. Same for "y" key.
I hope this is good for your needs also.
Regards,
-JJ

Jae-Joon Lee wrote:
> 
> 
> On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> 
> By the way, given that we now have "suplots" in the pyplot
> namespace,
> can we have sca also?
> 
> 
> Done in svn 8205.
> 
> 
> 
> Eric,
> 
> A minor question. I wonder whether an explicit for-loop inside 
> pyplot.sca is necessary?
> Here is a slight variation w/o a for-loop (well, the for-loop is 
> implicitly done with the "in" operator I guess) that seems to work for 
> me, but I may be missing something. 
> 
> managers = _pylab_helpers.Gcf.get_all_fig_managers()
> if ax.figure.canvas.manager in managers and \
> ax in ax.figure.axes:
> _pylab_helpers.Gcf.set_active(ax.figure.canvas.manager)
> ax.figure.sca(ax)
> return
> raise ValueError("Axes instance argument was not found in a figure.")
> 
> Regards,
> 
> -JJ
> 
JJ,
I think your version would need an additional try/except or conditional, 
because a Figure doesn't necessarily have a canvas assigned to it, and a 
canvas doesn't necessarily have a manager. Granted, the problem would 
arise only under odd circumstances involving a mixture of pyplot and OO 
styles--and maybe there is actually something that would prevent the 
problem from arising at all--but I would want to be sure the problem 
either was handled, or could not arise. So, I think my version ends up 
being simpler, safer, and easier to understand--at least for me.
Eric

On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...> wrote:
> By the way, given that we now have "suplots" in the pyplot namespace,
>> can we have sca also?
>>
>
> Done in svn 8205.
>
Eric,
A minor question. I wonder whether an explicit for-loop inside pyplot.sca is
necessary?
Here is a slight variation w/o a for-loop (well, the for-loop is implicitly
done with the "in" operator I guess) that seems to work for me, but I may be
missing something.
 managers = _pylab_helpers.Gcf.get_all_fig_managers()
 if ax.figure.canvas.manager in managers and \
 ax in ax.figure.axes:
 _pylab_helpers.Gcf.set_active(ax.figure.canvas.manager)
 ax.figure.sca(ax)
 return
 raise ValueError("Axes instance argument was not found in a figure.")
Regards,
-JJ

On Sun, Mar 21, 2010 at 2:30 PM, Eric Firing <ef...@ha...> wrote:
> Is the added complexity, scrambling pylab into the OO layer, and need for
> explanation, really worth the gain? As far as I can see, it merely adds
one
> more way to do something--and not a particularly recommended way. It is
no
> more concise than using sca(). It may be slightly more readable because
of
> the indentation, but that is the only advantage I see.
>
* complexity
 I guess the code below is a "minimal" implementation (it worked okay with
my limited tests).
 # context manager
 def __enter__(self):
 import matplotlib.pyplot as plt
 plt.sca(self)
 return self
 def __exit__(self, type, value, tb):
 pass
* readability
1) with "with" statement
fig, axarr = subplots(2,2)
> for ax1, ax2 in axarr:
 with ax1:
 plot([1,2,3])
> with ax2:
 plot([2,3,4])
2) with "sca"
> fig, axarr = subplots(2,2)
> for ax1, ax2 in axarr:
 sca(ax1)
 plot([1,2,3])
> sca(ax2)
 plot([2,3,4])
While I certainly prefer 1) over 2) as far as the readability is concerned,
I currently don't have a strong opinion whether the readability beats the
complexity in this case.
So, unless there are more of positive feedbacks from others, I'll consider
it dropped.
Regards,
-JJ

Ryan May wrote:
> On Sun, Mar 21, 2010 at 12:35 PM, Jae-Joon Lee <lee...@gm...> wrote:
>> On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...> wrote:
>>>> Or, how about we make axes an context manager.
>>> This would require dropping support for Python 2.4.
>> I don't think making the Axes a context manager means dropping python
>> 2.4 support
>> (note that I'm not saying we use "with" statement in the mpl source).
>> Everything should work fine in python 2.4 (please correct me if I'm wrong).
>> It just gives a user a choice. If a user runs his/her script with
>> python 2.5 and higher, he/she has an option to use an axes as an
>> context manager. Of course, if he/she want his/her own code supported
>> in python 2.4, he/she should not use "with" statement.
> 
> I see what you're saying. While the use of the language syntax is
> restricted to 2.5 and above, we could add the needed methods to the
> Axes object, which would just be ignored by python <2.5. That's not a
> bad idea.
> 
> I'm +1 on the idea.
Is the added complexity, scrambling pylab into the OO layer, and need 
for explanation, really worth the gain? As far as I can see, it merely 
adds one more way to do something--and not a particularly recommended 
way. It is no more concise than using sca(). It may be slightly more 
readable because of the indentation, but that is the only advantage I see.
Eric
> 
> Ryan
> 

On Sun, Mar 21, 2010 at 12:35 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...> wrote:
>>> Or, how about we make axes an context manager.
>>
>> This would require dropping support for Python 2.4.
>
> I don't think making the Axes a context manager means dropping python
> 2.4 support
> (note that I'm not saying we use "with" statement in the mpl source).
> Everything should work fine in python 2.4 (please correct me if I'm wrong).
> It just gives a user a choice. If a user runs his/her script with
> python 2.5 and higher, he/she has an option to use an axes as an
> context manager. Of course, if he/she want his/her own code supported
> in python 2.4, he/she should not use "with" statement.
I see what you're saying. While the use of the language syntax is
restricted to 2.5 and above, we could add the needed methods to the
Axes object, which would just be ignored by python <2.5. That's not a
bad idea.
I'm +1 on the idea.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...> wrote:
>
> Done in svn 8205.
>
Thanks!
>>
>> Or, how about we make axes an context manager.
>
> This would require dropping support for Python 2.4.
I don't think making the Axes a context manager means dropping python
2.4 support
(note that I'm not saying we use "with" statement in the mpl source).
Everything should work fine in python 2.4 (please correct me if I'm wrong).
It just gives a user a choice. If a user runs his/her script with
python 2.5 and higher, he/she has an option to use an axes as an
context manager. Of course, if he/she want his/her own code supported
in python 2.4, he/she should not use "with" statement.
Regards,
-JJ

Ryan May wrote:
> On Sat, Mar 20, 2010 at 5:53 PM, Eric Firing <ef...@ha...> wrote:
>> Ryan May wrote:
>>> Hi,
>>>
>>> I just started running PyGTK 2.16 and noticed the following everytime
>>> I run a matplotlib script:
>>>
>>>
>>> /home/rmay/.local/lib/python2.6/site-packages/matplotlib/backends/backend_gtk.py:621:
>>> DeprecationWarning: Use the new widget gtk.Tooltip
>>> self.tooltips = gtk.Tooltips()
>>>
>>> Right now, we support >= PyGTK 2.2. The new, non-deperecated API
>> pygtk_version_required = (2,4,0)
> 
> Ok. I got my number from our install docs:
> http://matplotlib.sourceforge.net/users/installing.html#build-requirements
> There it says PyGTK 2.2 as a (optional) build dependency.
Fixed in svn, thanks.
Eric

On Sat, Mar 20, 2010 at 5:53 PM, Eric Firing <ef...@ha...> wrote:
> Ryan May wrote:
>>
>> Hi,
>>
>> I just started running PyGTK 2.16 and noticed the following everytime
>> I run a matplotlib script:
>>
>>
>> /home/rmay/.local/lib/python2.6/site-packages/matplotlib/backends/backend_gtk.py:621:
>> DeprecationWarning: Use the new widget gtk.Tooltip
>> self.tooltips = gtk.Tooltips()
>>
>> Right now, we support >= PyGTK 2.2. The new, non-deperecated API
>
> pygtk_version_required = (2,4,0)
Ok. I got my number from our install docs:
http://matplotlib.sourceforge.net/users/installing.html#build-requirements
There it says PyGTK 2.2 as a (optional) build dependency.
>> (gtk.Tooltip) was added in 2.12 (and the gtk.Tooltips API was
>> deprecated at this time). So, my question is how do we want to handle
>> this? Do we want to create a helper method that hides the logic to
>> determine what method to use (there doesn't look to be an easy way to
>> support both)? Or do we just bump our required version? 2.12.0 was
>> released in fall 2007. I'm not sure what versions are supplied with
>> the various distros.
>>
>
> My sense is that RHEL4 is still common, and will be supported by RH through
> early 2012 (http://www.redhat.com/security/updates/errata/). It is way back
> at pygtk 2.4.
>
> I just now committed to svn a little bit of conditional code to support the
> new api along with the old one. Minimal testing on my system (new api)
> looks OK; more testing with new API, and testing with pygtk < 2.12, are
> needed. The changes are extremely simple, but I might have overlooked
> something.
Awesome, works great here, thanks.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Jae-Joon Lee wrote:
> 
> By the way, given that we now have "suplots" in the pyplot namespace,
> can we have sca also?
Done in svn 8205.
> For example,
> 
> # Two subplots, the axes array is 1-d
> f, axarr = subplots(2, sharex=True)
> 
> sca(axarr[0])
> plot(x, y)
> title('Sharing X axis')
> 
> sca(axarr[1])
> scatter(x, y)
> 
> Or, how about we make axes an context manager.
This would require dropping support for Python 2.4.
Eric
> 
> # Two subplots, the axes array is 1-d
> f, axarr = subplots(2, sharex=True)
> 
> with axarr[0]:
> plot(x, y)
> title('Sharing X axis')
> 
> with axarr[1]:
> scatter(x, y)
> 
> This may not very useful in the interactive mode, but may make a
> script (written in pylab mode) more readable.
> 
> Regards,
> 
> -JJ