using a recent svn (r8900), I've noticed that after starting from a regular python shell:
>>> import matplotlib.pyplot as plt
>>> plt.isinteractive()
False
>>> plt.plot([1,2,3],[1,3,2])
[<matplotlib.lines.Line2D object at 0x114e7a090>]
>>> plt.plot([1,2,3],[1,2,3])
[<matplotlib.lines.Line2D object at 0x114e7a590>]
# plt.draw() is not required, the figure pops up
# and both plots are shown
>>> plt.xlim(1,2)
(1, 2)
# again this works immediately no draw() required
>>> plt.xlabel('aaa')
<matplotlib.text.Text object at 0x1033a2290>
# ditto, no draw() required
but if the axes methods are used, then interactive status is honored:
>>> plt.gca().set_xlabel('bbb')
<matplotlib.text.Text object at 0x1033a2290>
>>> plt.gca().plot([1,2,3],[3,2,1])
[<matplotlib.lines.Line2D object at 0x114e7cf90>]
>>> plt.gca().set_xlim(1,3)
(1, 3)
# all these require a plt.draw() to show up...
I think that this is a misfeature, but maybe this is desired behavior?
M
Which backend are you using and using which OS?
Ben Root
···
On Mon, Feb 7, 2011 at 7:20 PM, Mike Kaufman <mckauf@…149…> wrote:
using a recent svn (r8900), I’ve noticed that after starting from a
regular python shell:
import matplotlib.pyplot as plt
plt.isinteractive()
False
plt.plot([1,2,3],[1,3,2])
[<matplotlib.lines.Line2D object at 0x114e7a090>]
plt.plot([1,2,3],[1,2,3])
[<matplotlib.lines.Line2D object at 0x114e7a590>]
plt.draw() is not required, the figure pops up
and both plots are shown
plt.xlim(1,2)
(1, 2)
again this works immediately no draw() required
plt.xlabel(‘aaa’)
<matplotlib.text.Text object at 0x1033a2290>
ditto, no draw() required
but if the axes methods are used, then interactive status is honored:
plt.gca().set_xlabel(‘bbb’)
<matplotlib.text.Text object at 0x1033a2290>
plt.gca().plot([1,2,3],[3,2,1])
[<matplotlib.lines.Line2D object at 0x114e7cf90>]
plt.gca().set_xlim(1,3)
(1, 3)
all these require a plt.draw() to show up…
I think that this is a misfeature, but maybe this is desired behavior?
M
Good question. Snow Leopard and the MacOSX backend. If I use the Gtk backend this bug does _not_ occur (though I have to use the plt.show() command to bring up the window --- which hangs the shell...)
M
···
On 2/7/11 9:02 PM, Benjamin Root wrote:
On Mon, Feb 7, 2011 at 7:20 PM, Mike Kaufman <mckauf@...149... > <mailto:mckauf@…149…>> wrote:
using a recent svn (r8900), I've noticed that after starting from a
regular python shell:
>>> import matplotlib.pyplot as plt
>>> plt.isinteractive()
False
>>> plt.plot([1,2,3],[1,3,2])
[<matplotlib.lines.Line2D object at 0x114e7a090>]
>>> plt.plot([1,2,3],[1,2,3])
[<matplotlib.lines.Line2D object at 0x114e7a590>]
# plt.draw() is not required, the figure pops up
# and both plots are shown
>>> plt.xlim(1,2)
(1, 2)
# again this works immediately no draw() required
>>> plt.xlabel('aaa')
<matplotlib.text.Text object at 0x1033a2290>
# ditto, no draw() required
but if the axes methods are used, then interactive status is honored:
>>> plt.gca().set_xlabel('bbb')
<matplotlib.text.Text object at 0x1033a2290>
>>> plt.gca().plot([1,2,3],[3,2,1])
[<matplotlib.lines.Line2D object at 0x114e7cf90>]
>>> plt.gca().set_xlim(1,3)
(1, 3)
# all these require a plt.draw() to show up...
I think that this is a misfeature, but maybe this is desired behavior?
M
Which backend are you using and using which OS?
using a recent svn (r8900), I've noticed that after starting from a
regular python shell:
>>> import matplotlib.pyplot as plt
>>> plt.isinteractive()
False
>>> plt.plot([1,2,3],[1,3,2])
[<matplotlib.lines.Line2D object at 0x114e7a090>]
>>> plt.plot([1,2,3],[1,2,3])
[<matplotlib.lines.Line2D object at 0x114e7a590>]
# plt.draw() is not required, the figure pops up
# and both plots are shown
>>> plt.xlim(1,2)
(1, 2)
# again this works immediately no draw() required
>>> plt.xlabel('aaa')
<matplotlib.text.Text object at 0x1033a2290>
# ditto, no draw() required
but if the axes methods are used, then interactive status is honored:
>>> plt.gca().set_xlabel('bbb')
<matplotlib.text.Text object at 0x1033a2290>
>>> plt.gca().plot([1,2,3],[3,2,1])
[<matplotlib.lines.Line2D object at 0x114e7cf90>]
>>> plt.gca().set_xlim(1,3)
(1, 3)
# all these require a plt.draw() to show up...
I think that this is a misfeature, but maybe this is desired behavior?
M
Which backend are you using and using which OS?
Good question. Snow Leopard and the MacOSX backend. If I use the Gtk
This is a known bug in the MacOSX backend.
backend this bug does _not_ occur (though I have to use the plt.show()
command to bring up the window --- which hangs the shell...)
It should simply block until the window is closed; is this what you mean?
Eric
···
On 02/07/2011 04:13 PM, Mike Kaufman wrote:
On 2/7/11 9:02 PM, Benjamin Root wrote:
On Mon, Feb 7, 2011 at 7:20 PM, Mike Kaufman<mckauf@...149... >> <mailto:mckauf@…149…>> wrote:
M
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Yes I do, although I'm not sure why it should block: I may want to add additional plots to the window --- though I do notice that if isinteractive=True, then the window doesn't block. It makes sense I guess, but not really intuitive, especially not coming from the behaviour of the OSX backend.
M
···
On 2/7/11 9:28 PM, Eric Firing wrote:
Which backend are you using and using which OS?
Good question. Snow Leopard and the MacOSX backend. If I use the Gtk
This is a known bug in the MacOSX backend.
backend this bug does _not_ occur (though I have to use the plt.show()
command to bring up the window --- which hangs the shell...)
It should simply block until the window is closed; is this what you mean?
The behavior in gtk and other backends is the designed/intended behavior. macosx backend is actually the odd-man out because it was coded to only work in one of those modes.
Maybe we should emit a warning when macosx backend is used when interactive=False in order to dispel misunderstanding?
Ben Root
···
On Mon, Feb 7, 2011 at 9:17 PM, Mike Kaufman <mckauf@…322…9…> wrote:
On 2/7/11 9:28 PM, Eric Firing wrote:
Which backend are you using and using which OS?
Good question. Snow Leopard and the MacOSX backend. If I use the Gtk
This is a known bug in the MacOSX backend.
backend this bug does not occur (though I have to use the plt.show()
command to bring up the window — which hangs the shell…)
It should simply block until the window is closed; is this what you mean?
Yes I do, although I’m not sure why it should block: I may want to add
additional plots to the window — though I do notice that if
isinteractive=True, then the window doesn’t block. It makes sense I
guess, but not really intuitive, especially not coming from the
behaviour of the OSX backend.
M
possibly, but maybe adding a blurb about OSX, and maybe the blocking behavior to the documentation here: http://matplotlib.sourceforge.net/users/shell.html and maybe to the dostrings of ion(), ioff() would be good.
M
···
On 2/7/11 10:30 PM, Benjamin Root wrote:
The behavior in gtk and other backends is the designed/intended
behavior. macosx backend is actually the odd-man out because it was
coded to only work in one of those modes.
Maybe we should emit a warning when macosx backend is used when
interactive=False in order to dispel misunderstanding?