Evaluating IDEs for scientific Python

* Last updated May 27th, 2013 *

Python is a general purpose scripting language that can be used for statistical analysis, numeric work, machine learning, etc. With packages like SciPy, matplotlib, CUDAmat/gnumpy, Theano, and Scikit, it’s a worthy, free competitor to Matlab.

Of course, Matlab is more than its scripting language; it’s an integrated development environment (IDE) which combines editing, execution, plotting, debugging, etc. Here I evaluate 4 IDEs for scientific Python on my Ubuntu 11.10 PC to see how they stack up to Matlab:

  • IEP 3.2
  • Spyder 2.2
  • PyDev 2.7 + ipython
  • Enthought Canopy 1.0 (commercial)

Generally, these IDEs combine a text editor, an integrated python shell (python or ipython), support for interactive plotting via matplotlib as well as several other features to tie everything together.

Criteria for evaluation

Python has support for many features of the Matlab IDE at the language level. The interactive Python shell has support for interactive execution and integrated help (simply type help(object)). Profiling can easily be done via the cProfile module:

import cProfile as profile
profile.run('myfun()')

Variables can be listed via dir() or locals() and inspected via the shell. Python also has support for creating GUI interfaces – for instance, via QT or GTK – which put GUIDE to shame.

Given this, the most important features for a Python IDE geared toward science are:

  • A kick-ass text editor with introspection, autocomplete and so forth
  • Seamless integration of Python shell and text editor
  • Interactive plotting via matplotlib
  • Seamless debugging
  • An undefinable quality of well-thought out programs that causes a zen-like experience; for lack of a better term, smoothness

IEP

IEP, the interactive editor for Python, is

a cross-platform Python IDE focused on interactivity and introspection, which makes it very suitable for scientific computing.

The most notable feature of the user interface is its support for various Run commands which mimic those of Matlab. F5 will execute the currently edited Python file, F9 the current selection, while Ctrl+Enter will execute the current cell. Cells are defined via ##, equivalent to Matlab’s %%. This is a very neat feature.

An aside on dynamic loading and execution

To work comfortably with the interface, it’s important to understand how Python loads modules and functions compared to Matlab. In Matlab, if you have changed a function and save the file, on your next call Matlab will use the new definition.

In Python, it’s different. If I have a file testcmd.py which I import via import testcmd, if I then change testcmd.py, neither executing testcmd.py nor running import again will load the updated definition. reload(testcmd) must be called for the definition to be updated.

That means that IEP’s various interactive run modes work best when the function to be tested and the code executing it belong in the same file. While in Matlab a script file cannot contain function definitions, in Python script files can contain functions, classes, and procedural code, so this is not as limiting as it may appear at first.

It should also be noted that when a class is redefined in Python, any objects created before then will still use the old definition. For instance:

class Bob(object):
    def __init__(self):
        self.myvar = 1

    def print_bob(self):
        print "Old myvar is:"
        print self.myvar

bob = Bob()
bob.print_bob()

class Bob(object):
    def __init__(self):
        self.myvar = 2

    def print_bob(self):
        print "New myvar is:"
        print self.myvar

bob.print_bob()
bob2 = Bob()
bob2.print_bob()

#rebind
bob.__class__ = Bob
bob.print_bob()

Results in:

Old myvar is:
1
Old myvar is:
1
New myvar is:
2
New myvar is:
1

Note that binding to the new class is accomplished via setting the __class__ property of the old object. I wish that this information was included in the IEP tour, because it’s very important to understand these things in order to take advantage of the interactive execution.

Back to IEP

IEP has post-mortem debugging (checking the state of things when the last uncaught exception occured) via a Debug button – limited, but serviceable.

The editor is pretty good – it has auto-completion, live introspection (it knows that bob2 has a print_bob function), function signature hints, and it shows a tree of class/function definitions.

matplotlib is supported via the following settings in .matplotlib/matplotlibrc:

interactive : True
 backend : Qt4Agg

Then setting the GUI to Qt in the shell configuration in IEP.

What IEP lacks in features, it makes up for in smoothness. Although the features are limited, they’re well thought out, and polished.

So:

  • Editor: 3/5
  • Interpreter integration: 4.5/5
  • Plotting: 2/5
  • Debugging: 2.5/5
  • Smooth: 4/5

Overall score: 3.5/5

Spyder

Spyder is

a powerful interactive development environment for the Python language with advanced editing, interactive testing, debugging and introspection features

Perhaps the most notable feature of Spyder is that it uses ipython as its default command line environment – see here for an in-depth review of ipython and ipython Notebook. As such, it has built-in support for Matplotlib. Using ipython also alleviates some of the issues with editing modules, since ipython supports auto-reloading modules, via typing at the interpreter:

import ipy_autoreload
%autoreload 2

Spyder supports running a selection (F9) and a file (F5) from within the editor, but no Ctrl+Enter for cell mode-like execution.

Spyder’s editor is excellent. It offers deep introspection, highlights errors, gives warnings, and opens up the docstring information upon calling a function. Errors and warnings are shown on the left hand side of the line number and can be inspected via clicking and holding over the error and warning icons – unintuitive, but workable. Upon highlighting a word, it automatically highlights all other instances of the word in the editor – handy for tracking variables.

The editor can find the file/line where a function was defined by holding the Ctrl button and clicking the function name – similar to the Ctrl+D – Open definition feature in Matlab.

It has support for setting breakpoints within the interface, and feeds that information to the pdb debugger.

pdb can then be manipulated via its command line interface inside ipython: c to continue, u to go up a level, q to quit, etc. New in 2.2, GUI equivalents for the debugger have been added.

It would be an ideal package were it not for its lack of polish. The project explorer – there is also an unrelated, but largely overlapping file explorer – is deeply confusing and annoying. The interface used to be messy and confusing, with toolbars for buttons you will never use – but this has been significantly improved in version 2.2, in part in response to the previous review in this very blog – kudos to the developer! I also found installation on Windows to be annoying.

To sum up:

  • Editor: 4/5
  • Interpretor integration: 4/5
  • Plotting: 4/5
  • Debugging: 4/5
  • Smooth: 3/5 (up from 2/5 for version 2.0)

Total: 3.8/5

PyDev + ipython

PyDev is a Python IDE for Eclipse. Eclipse is kind of a meta-IDE for a bunch of languages. I wouldn’t call it smooth – it’s built like a tank. While it has a fantastic editor with deep introspection, support for refactoring and a gorgeous graphical debugger, it doesn’t play well with matplotlib. Specifically, it hangs when calling draw.

Thus, you have to keep a separate ipython window open. A file may be run in ipython via the command:

run myfile.py

It’s a workable, if inelegant solution. I would recommend PyDev to those doing hardcore development in Python – for more casual users, look elsewhere.

  • Editor: 5/5
  • Interpretor integration: 2/5
  • Plotting: 0/5
  • Debugging: 5/5
  • Smooth: 2/5

Overall score: 2.5/5

Enthought Canopy

Finally, we have a commercial editor from Enthought called Canopy, which, according to them

is a comprehensive Python analysis environment with easy installation & updates of the proven Enthought Python distribution

I installed the academic version, which required acquiring a license via my mail.mcgill.ca address. It wouldn’t open. In the command line, I get the error:

/home/patrick/Canopy/appdata/canopy-1.0.0.1160.rh5-x86_64/bin/python: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0: undefined symbol: g_source_set_name

I tried every trick in the book to get it running, but couldn’t figure it out. I figured I would try support, but Enthought redirects users to ask questions on StackOverflow, which is basically a way of saying to free users: you’re shit out of luck.

But I’m a good sport, so I decided to install it on another computer (Ubuntu 12.04LTS) to see if it would work. Here I got a different error:

QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries.

And then Google wasn’t helpful, so I gave up. Easy installation, eh?

Score: minus eleventy

Canopy turned out to install fine on Windows, and I review it here.

About these ads
Evaluating IDEs for scientific Python

40 thoughts on “Evaluating IDEs for scientific Python

  1. zhenghd says:

    Thank for your sharing.
    I have a question: why my iep’s code colr not the same with you.Is there any setting?thanks.

  2. Ido says:

    Thanks for a great Overview. Im also using python for scientific research, and this has been very helpful. Iv’e tried several python IDEs in the last month or so, and still havent find the best for me. My needs, in importance order:

    1. Very good interactivity and plotting abilities
    2. Seamless debugging – setting breakpoints in the editor, ability to examine variables while in breakpoints, ability to interactively code while in breakpoints.
    3. Good editor, good IDE environment, Good project management capabilities

    These are my impressions, I’ll be glad to here your opinion:

    1. Iv’e started with the IPython notebook. as fun as it was to add notes and explanations while coding, and as beautiful as the outcome appear, it is not suitable for researching projects in general, as the notebook gets larger and not coherent very fast. I sometimes try many methods before I find the right why to go, and I dont need all the trails in my notebook. IPython notebook is great to summarize your work once you figured what to do and want to record the process and explain the research path.

    Also, the notebook is not meeting any of the criterias above reasonably. Interactivity is limited. yes, you can right code and see the output immediately, but that code is staying in your notebook and catches many cells you dont want to be seen. Debugging is a pain also. very very limited and not friendly. Managing the code is also not easy, copy pasting cells or moving cells around is done cell by cell, which can be very annoying when trying to move many cells. Eventually, the IPython notebook is really great for recording the research progress and sumrizations, but not for the project advancements it self.

    2. So then I tried Spyder. For my taste, spyder is a beautiful IDE. I loved the HTML look, the instant info on function and the overall design. The F9 to run a code is very handy, and it meets objective number 1 very good (4/5) I disliked the fact that one changing a function in the editor, I need to mark it and do F9 for the change to take effect in the console, but that was minor. My biggest problem with spyder was the debugger. I dont know how you scored it 4/5, I would score it 2/5. It is a simple PDB debugger. while PDB might be very powerful for users how knows it good, it is not a GUI debugger and for me can not serve as one. Also, the debugger in spyder is not consistent and tends to halt. I also find it difficult to examine local variables while in BP which misses completely the power of debugging in scientific research. To sum it, Spyder is great when I dont make mistakes, but when I do make mistakes, It is much harder to track them in spyder then it is on WING.

    3. So I tried WING IDE next. It was good. very nice overall development environment. very suitable for big research projects. very nice code completion and re factoring capabilities. The debugger is very good too. The only problem with it is that is a little ugly.. the GUI colors selection is awful, the toolbars are ugly, the help documentation is not readable without struggling, fonts are ugly too… and also the interactive capabilities and minimal. No integration with an IPython console, so graphing is less seamless (figures are created in a separate window) and no integration with Pandas. So it is reasonable, but It is not fun. and we want to enjoy the aesthetics, make us more productable, isnt it so? :)

    So Im still looking for the best IDE for me. I going to try pydev with IPython now. I have a feeling it might be the winner for me. Would appriciatie comments. did I miss anything?

  3. Hi there, just wanted to say that the interactive console in PyDev is getting a lot of attention and the latest release improved on that area a lot (there are details at http://pydev.blogspot.com.br/2013/11/pydev-30.html — and it plays well with matplotlib now). This area is also expected to improve even more in the upcoming releases (it may be interesting following DAWN too: http://www.dawnsci.org/, which bundles PyDev and is targeted at scientific data analysis).

  4. Niels Anders says:

    thanks for the review. It’s nice to see my favorite IDE scores highest in your comparison (spyder). With respect to the plotting I wish to see something like RStudio, where figures can be docked, but that’s just details. I have been using it for 3 years now, mainly on linux, occasionally on windows.

    The reason I looked for (different) IDE’s is that Spyder keeps crashing on my plots. I use multiprocessing and matplotlib with gtk backend to update a master figure. Other backends do not update plots when used with multiprocessing, and gtk often crashes my IDE after the process is finished and I try to make some edits in the script. Anyway, I didn’t find any better alternative than Spyder and after this blog I don’t think I’ll look further. I’ll look into the iPython integration, I never looked into that (not enabled by default on my installation).

  5. dantheman says:

    Patrick – I installed spyder on windows 7 and could not find any link or icon to an executable.
    It just disappeared which is about the most pointless install I have ever seen. Where to they put the link to run the app – its not in programs (as it should be). It doesnt install in registry etc. Really frustrating.

    1. ccordoba12 says:

      Hi dantheman, I’m an Spyder developer. May I ask you how you installed Spyder? Did you use a scientific distribution (PythonXY, WinPython), our Windows installers or pip?

    2. EJ says:

      Since this is a question from a year ago, I think my answer will serve people who have the same question and come across here.

      You can launch it by going to windows DOS prompt mode. Simply click start, type in cmd in the search bar and launch command mode, then type spyder to launch it. Or maybe simply type spyder in the search bar and see if you can launch it directly.

  6. unixengr says:

    Whatever you do, don’t purchase the KomodoIDE for Mac. It boasts lots of features that do not work. Save your money or purchase PyCharm from Jetbrains. They have excellent support and the product works well. Don’t waste your time and money on Komodo IDE 8. The product is JUNK!

  7. ccordoba12 says:

    (Disclaimer: Spyder dev here). Hi Patrick, thanks a lot for your evaluation. I’ll take into account your suggestions for our next release (about to be released):

    1. I’ll remove unnecessary toolbars to diminish visual clutter. This is a real problem with IDEs, i.e. they could be cluttered quite easily in their attempt to visually show the user all the cools things they can do. But you’re right: most of those things are not constantly used, so they can hidden by default.

    2. I didn’t know tooltips were so annoying. They are meant to show only signatures because for docstrings there is our Object Inspector (which shows them in rich text). I think the best thing to do would be to join them to the completion widget, as PyDev and Rstudio do. Another option would be to leave them open until the user starts to write some text. What do you think would be the best option?

    1. xcorr says:

      1. I think by default the toolbars should be arranged by default like so, starting from the left:
      New, open, save, save all (no print button). Run (contextual, so that when a selection is highlighted it runs the selection and not the whole file), debug, config. You really don’t need more than that. All the tooltips on hover should show the corresponding keyboard shortcuts.

      The working directory toolbar should be integrated into the “project” panel. The file explorer panel should not be shown by default, since most of the time it’s redundant with the project panel. The Outline panel should be integrated with the object inspector and variable inspector. Object inspector should be renamed “online help” or something similar. History log should be integrated with the console panel. The Options button in the editor should only show actual viewing options, like tile vertically, new window, and the like. Every panel comes with an options button, yet some have “Options” written next to the button, others not. Choose one.

      2. I like PyDev’s solution, personally. You could show a short version of the docstring and keep the full version for the object inspector panel. You could have object inspection tied to highlighting, or to a keyboard shortcut (say, shift+F1 for contextual help). Also, if you could have an “open definition” option that would open the definition of a function/class on highlight, like Matlab’s Ctrl+D, that would be great.

      1. ccordoba12 says:

        1. I’ve made most of the changes you suggested to our toolbars in 2.2. But to see them you have to remove your ~/.spyder2 dir and restart Spyder.

        I don’t think making “Run” contextual is a good idea, but I’ll give it more thought when we introduce cells in 2.3.You’re probably right about the run buttons that should be changed by “play” ones, but we are not gonna do it for 2.2, maybe for 2.3.

        It’s not easy to add keyboard shortcuts to our tooltips because all of them are configurable. But it’s something we could try for 2.3.

        The Working directory toolbar controls the working dir for all our consoles (Python and IPython), so I don’t think it’s a good idea to add it to the project plugin. Besides, Matlab also has it as part of its main toolbar, so it’ll give some familiarity to its users.

        Since our project functionality is not too strong, it’s better to leave file explorer where it is now.

        The outiline explorer is designed to let you navigate your code, so I think it’s better to leave it next to the Editor (as it is now).

        The object inspector will be renamed to “Online help” when we add some documentation on how to use Spyder in 2.3. For now it only inspect objects.

        I think you are right about the Editor options menu and the “Options” label in some buttons and not in others. I’ll fix it this week.

        2. I have an idea on how to improve our tooltips so that they work as in other IDEs (but that’s work for 2.3). Although I don’t like PyDev’s tooltips (because when attached to the completion widget they took to much screen space), we could add a config option to made them work that way.

        There is already an “open definition” functionality: Just keep pressed Ctrl and move the mouse to the function/method you want to inspect. You’ll see that it will be highlighted as a browser hyperlink (i.e. its color will change to blue and will be underlined). If you left click on it, it will open the file where it is defined. I know it’s not easy to find :)

    2. xcorr says:

      Also the icon for Run should be a green arrow pointing towards the right (“Play”) rather than a little running man. It’s standard for “Run” to represented by a play button.

    3. xcorr says:

      I tried the latest version. I like it a lot – definitely seems more polished. I noticed little things like the fact that it shows an icon in the Ubuntu menu, whereas it didn’t before, and it’s now the Programming menu rather than Menu. I dig the new toolbar arrangement, very much like what I had in mind. I see that you’ve changed the behaviour of the outline panel too, I like it (although below everything else might not be the best default placement).

      The only thing I didn’t like about the new default configuration is that the iPython console is closed by default and the python console is open. I think it should be the other way around. It might be good to have the ipython console open by default with load_ext autoreload, autoreload 2 running by default to facilitate the transition for Matlab users. Excellent job.

      1. ccordoba12 says:

        First of all, I’m glad you liked it my changes :) Your criticism was very up to the point and helped us to polish much more our interface.

        About IPython: I was just thinking this is the way to go, i.e. show the IPython console and hide the Python one, so you’re basically reading my mind! :) This would help to avoid confusion on having two evaluation interfaces and promote IPython as our preferred one. However we didn’t want to delay 2.2 more time so we’ll do this change in 2.3.

        I’ll see what we can do about autoreloead, seems very interesting.

    4. xcorr says:

      Actually I just tried the project view and I was very confused about the project/workspace distinction. I created a workspace and a project in the same directory and I was expecting the files to show up in the project panel. Rather, I don’t see the files, and when I try to import the directory specifically it says that it’s already open. I have no idea what’s going on.

      1. ccordoba12 says:

        Projects are our weak point right now. They are unintuitive and not well integrated with our other plugins. We’ll work on improving them in 2.3.

        My main idea is to copy the way RStudio defines projects, which seems very well thought.

    5. xcorr says:

      ANNNNND it just showed up after I changed the workspace directory (I think?) so that it was one folder up from the folder I was interested in using.

    1. xcorr says:

      I haven’t, but it doesn’t look like it has a set of features particularly aimed at science. I don’t plan on reviewing other IDEs unless they claim integration with matplotlib, ipython or dynamic interaction with the Python console.

  8. Corran Webster says:

    First the disclaimer: I work for Enthought as a developer, although not on Canopy itself at the moment.

    I’m sorry you ran into such profound difficulties with Canopy. Right now Canopy Linux (unlike the OS X and Windows versions) is in public beta and has been out for less than 2 weeks, so it’s not entirely surprising that there may be issues with it. Please help us diagnose and fix them via Enthought’s support system – there’s a fair chance that any common issues already have a known work-around.

      1. prabhuramachandran says:

        Apologies for your troubles with Canopy. I work at Enthought and have been trying to reproduce your problem but on a machine with Ubuntu 12.10. I installed the 64 bit version and although I do get the message “QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries.” Canopy does launch and run fine. I have tried this with Unity and also with the Gnome classic interface. A colleague has tested Canopy on 12.04 and has not had problems. If you have any additional debug information on the issues please do let me know. For example, do you have your PYTHONPATH or LD_LIBRARY_PATH env vars set to anything?

        Thanks.

  9. Now I am curious, I wonder if I would be able to make Canopy run… your article left me a bad taste :/ Thank you for the other three anyway! Right now I’m doing well with IEP because it’s smooth and lightweight, it’s what I recommend to everybody.

    1. I’ve been using Canopy for a MOOC where it was suggested as the default environment. Sadly, no debugger yet, which is a big downside. Also, the steps to handle abort are pretty clunky.

  10. TomP says:

    Yes, I’m surprised there was no mention of iPython. It’s not an IDE, because it has no editor, but it’s so well integrated with scipy and matplotlib that it’s a very nice way to do Matlab-like work in python.

    1. xcorr says:

      I really like ipython. I talk about using ipython + using your favorite editor in the PyDev section. It’s a workable solution, but there’s a lot of advantages in having the interpreter integrated with the editor, as is the case with IEP and Spyder, like the ability to highlight a snippet of code in the editor and run it, and having the editor open the relevant file and highlight the right line after an error/when debugging.

  11. Bernard says:

    While I know it’s not technically an IDE, you should really consider the IPython notebook. It’s really what converted me from working mainly in Matlab to almost exclusively in Python. Since a lot of what I do is largely interactive work, stumbling my way through ideas and results, having a log of all of that in notebook form is great.

      1. Ido says:

        Really? you really think is great? I LOVE the notebook idea but i cant see how to use it besides to sum up a project. I find it improper for fast algorithmic develpoment (as I expect from a matlab replacer). Maybe Im using it wrong?

        What im lacking in comparison to matlab:
        1. a “running a selection” option. When im trying something new, I dont want the entire cell to be run. and since the alt+enter not working for me (for some reason) i cant enter the middle of the notebook and easily start trail an error session.

        2. Also, I dont like to “mess up” the notebook with trail and error code. I would happily do that in “aside” interpeter that knows all the workspace variables, but not in the notebook…

        3. No debugger, No variable watch. How can someone live with that? What if i want to run code to do some funcionality, and run it command by command and make sure in each step variables holds what they suppose to hold? in Ipython, that would mean printing a variable after each step, which again, mess up the code. i find this lack of “watch” to really slow me down.

        How do you get over this? Am I using it wrong? because it is a beautiful tool that i cant really seem to use as productivly as matlab. Ill aprriciate any comments.

        BTW, if the notebook could contain another regular Interpretor that knows the workspace variables and could run commands aside of the notebook, that would segnificantly improve the workability for me..

    1. xcorr says:

      I tried it for a day or so. The integration with the Python shell is minimal, that is, you can run a full file, but you can’t highlight a snippet and run it directly. The interface is bloated IMHO. The editor is all right, on par with Spyder. Overall, it’s more for the hardcore developer than for the casual scientific user.

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s