Matplotlib conflicts with IDLE

Date: Fri, 05 Feb 2010 12:59:41 -0800 From: Christopher Barker <Chris.Barker@...259...> Subject: Re: [Matplotlib-users] Matplotlib conflicts with IDLE To: matplotlib-users@lists.sourceforge.net Message-ID: <4B6C86BD.3090801@...259...> Content-Type: text/plain; charset=ISO-8859-1; format=flowed David MacQuigg wrote:

> I can't get Matplotlib to work with IDLE.
    
Sorry, I don't know anything about IDLE, but...

> I'm running on Mac OS-X, so it looks like IPython is not an option.
    
Why not? I use Ipython on OS-X all the time, and it is fabulous, really fabulous.

> Also, I
> would rather stick with IDLE. It is the perfect IDE for non-CS students who
> shouldn't be spending their time on the complexities of a plotting package.
    
Spyder:

http://packages.python.org/spyder/

Looks really promising, but I don't think they've got OS-X packages yet.

-Chris
  
Hi there,

I can confirm that Spyder will make these GUI event loop issues go away (BTW I saw it running on OS-X, 2 days ago -- note that it requires PyQt to be installed). If you are familiar with MATLAB's IDE, you won't be disappointed because it works almost the same way (it even communicates well with MATLAB thanks to .mat files import/export features).

The great advantage of Spyder over other Python IDEs is the exclusive "Workspace" feature: like MATLAB's workspace, that is a global variable explorer allowing GUI-based edition of the most used Python objects (integers, floats, strings, dictionaries, lists, NumPy arrays, ...). It seems unbelievable, but Spyder is really the only IDE providing this feature which is IMHO essential for scientific users.

Cheers,
Pierre

I'd like to pitch here the reason why I think there is a huge gain in
using IPython, because I think that not everybody realizes this.

For me, the killing feature is '%debug'. It enables you to drop in the
debugger post mortem. That means that if there is an exception raised
during a calculation, I can drop right where the exception occurred and
inspect the variables there. I can for instance check if a numpy array
has NaNs, and if so where they are, or if a matrix that is supposed to be
symmetric really is. I can also go up the call stack, and see what the
variables are at each level of function calls. Here is a trivial example:

In [1]: def f(x, y=0):
   ...: z = x+y
   ...: return 1/z
   ...:

In [2]: f(0)

···

On Sat, Feb 06, 2010 at 11:27:50AM +0100, Pierre Raybaut wrote:

> Why not? I use Ipython on OS-X all the time, and it is fabulous, really
> fabulous.

>> > Also, I would rather stick with IDLE. It is the perfect IDE for
>> > non-CS students who shouldn't be spending their time on the
>> > complexities of a plotting package.

> Spyder:
> http://packages.python.org/spyder/
> Looks really promising, but I don't think they've got OS-X packages yet.

> [snip]

---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call
last)

/home/varoquau/<ipython console> in <module>()

/home/varoquau/<ipython console> in f(x, y)

ZeroDivisionError: integer division or modulo by zero

In [3]: %debug

<ipython console>(3)f()

print x

0

print y

0

print z

0

Jose Unpinco has written a nice video introducing these features:
http://showmedo.com/videotutorials/video?name=7200060&fromSeriesID=720

When you start having a somewhat complex set of functions that call
each other, or when you are getting failures with somebody else's code,
this is priceless. This is so useful that to debug some code that, when I
am trying to understand why some code is not working the way it should
be, I will purposely add an exception, to be able to introspect the code.
Granted, adding pdb.set_trace() will work without IPython[*], but I find
it very useful.

I am to the point where the post-mortem debugging of IPython may be the
killing feature of Python that I lack with every other work flow. The
reason being that I develop data processing code, and that I am always
experiment and trying to implement new algorithms. As a result, my code
is seldom mature, and I often spend time tracking down where bugs lie.
Also, running my various processing steps take a while. This is why I
rely a lot on post-mortem: I find bugs after minutes or hours of number
crunching, and I want to be as efficient as possible. Post-portem enables
me not to restart the script that crashed.

My 2 cents,

Gaël

[*] It will not work in Spyder as it is quite challenging to have these
features requiring user terminal interaction in a GUI.

2010/2/6 Gael Varoquaux <gael.varoquaux@...1818...>:

···

On Sat, Feb 06, 2010 at 11:27:50AM +0100, Pierre Raybaut wrote:
When you start having a somewhat complex set of functions that call
each other, or when you are getting failures with somebody else's code,
this is priceless. This is so useful that to debug some code that, when I
am trying to understand why some code is not working the way it should
be, I will purposely add an exception, to be able to introspect the code.
Granted, adding pdb.set_trace() will work without IPython[*], but I find
it very useful.

[*] It will not work in Spyder as it is quite challenging to have these
features requiring user terminal interaction in a GUI.

Actually it works in Spyder too (in the external console which is
executed in a another process).
:wink:

-Pierre

Pierre Raybaut a écrit :

2010/2/6 Gael Varoquaux <gael.varoquaux@...1818...>:
  

When you start having a somewhat complex set of functions that call
each other, or when you are getting failures with somebody else's code,
this is priceless. This is so useful that to debug some code that, when I
am trying to understand why some code is not working the way it should
be, I will purposely add an exception, to be able to introspect the code.
Granted, adding pdb.set_trace() will work without IPython[*], but I find
it very useful.

[*] It will not work in Spyder as it is quite challenging to have these
features requiring user terminal interaction in a GUI.
    
Actually it works in Spyder too (in the external console which is
executed in a another process).
:wink:

-Pierre
  

Two screenshots to prove it :slight_smile:

Running an example script including "pdb.set_trace()" in the external console:
http://spyderlib.googlegroups.com/web/pdb_test.png
Executing the same script from a Python interpreter within the external console:
http://spyderlib.googlegroups.com/web/pdb_test2.png

-Pierre

···

On Sat, Feb 06, 2010 at 11:27:50AM +0100, Pierre Raybaut wrote:

Nice. I am not sure why when I tried it, it didn't work. I don't have
spyder around to test.

Gaël

···

On Sun, Feb 07, 2010 at 09:59:04AM +0100, Pierre Raybaut wrote:

Two screenshots to prove it :slight_smile:

Running an example script including "pdb.set_trace()" in the external
console:
http://spyderlib.googlegroups.com/web/pdb_test.png
Executing the same script from a Python interpreter within the external
console:
http://spyderlib.googlegroups.com/web/pdb_test2.png

Gael Varoquaux a �crit :

  

Two screenshots to prove it :slight_smile:

Running an example script including "pdb.set_trace()" in the external console:
http://spyderlib.googlegroups.com/web/pdb_test.png
Executing the same script from a Python interpreter within the external console:
http://spyderlib.googlegroups.com/web/pdb_test2.png
    
Nice. I am not sure why when I tried it, it didn't work. I don't have
spyder around to test.

Ga�l
  

I suppose you tried it in the interactive console (Spyder's internal console) which does not support pdb indeed.
Anyway, the external console is probably not the ultimate scientific console mainly because it does not support matplotlib in interactive mode for now (actually, I still haven't heard any complaint on this point because people use the interactive console for interactive work -- e.g. analyzing and visualizing data -- and the external console for application development). But I guess I could make it work eventually.

-Pierre

···

On Sun, Feb 07, 2010 at 09:59:04AM +0100, Pierre Raybaut wrote: