IDLE Chatter

I discussed IDLE way back in March 2001 when this column first looked at Python IDEs (see Resources for a link). In general outline, those remarks are still accurate, but IDLE has added lots of little finishing touches and improvements in the meanwhile. For this look, I downloaded IDLEfork 0.9b1. The IDLEfork project is designed as a place to test improvements to IDLE, with the intention of rolling the successful ones back into IDLE itself. The latest IDLEfork, 0.9b1, has a number of really significant improvements over basic IDLE, enough so I recommend you download it if you plan to use IDLE. It is now possible to interrupt code that is caught in a loop when test-run; runs also create a clean environment for themselves (avoiding namespace contamination). Also of interest is the new GUI configuration screen, which is much friendlier than digging through READMEs to figure out which internal files to change.

Figure 2. Running IDLE

IDLE starts out as an enhanced interactive shell window (with a bit better cut-and-paste, scrollback, etc. than the basic interactive prompt). I have mixed feelings about the command recall, where you need to move the cursor to the line you want to repeat. I think I prefer the readlines-style of jEdit's Jython or the Python shell. For most development the Python-aware editor is what you will use (no code-folding, but nice syntax highlighting and code-completion). You also get a class browser and debugger.

The menus in IDLE are Tk "tear-off" style; that is, clicking on the dashed line at the top of any pull-down menu will promote that menu to its own persistent window. The "Edit" menu in particular is nice if kept "docked" at the side of your desktop. IDLE's debugger provides breakpoints, stepping and variable watches; but nothing so fancy as poking at memory locations and variable contents, or performing timings and other analyses.

IDLE has most of the nice touches you want in a Python editor: commenting/uncommenting blocks; indenting/dedenting; regular expression searches; jump to line; and converting tabs to spaces or the reverse. Nothing hugely elaborate, but well-focused on those things you most need for Python. I really like the bold color choices in the syntax highlighting, though most editors are configurable, and just present more muted colors by default. Unfortunately, on Mac OS X, not all the key bindings work -- but this is either an issue with the X11 support, or an upshot of the fact that I have not gotten a working Tk/Aqua on my system. IDLE itself is blameless; in testing I just used the mouse to get at more menus than I would have liked. Linux systems usually do a better job with getting the key bindings right, though part of that depends on which window manager you use.

IDLE remains your best choice if you want a general Python IDE/editor that works on most platforms and does not require anything beyond Python itself and Tkinter.

A tangled Web

Over time, I have had quite a number of readers approach me to recommend Leo. Leo is a very different kind of application from the other editors/IDEs I discuss, or really from almost anything most readers will have worked with. The insight that prompts Leo is Donald Knuth's concept of "literate programming" -- that is, the idea that the source code for a program is only a small part of what makes it up. The real body of a program is descriptions of its algorithms, structure, purpose, and usage -- the source code that implements it is almost incidental. That is the concept anyway; I am not quite convinced, but neither am I sure the idea is wrong.

Figure 3. Welcome to Leo

A Leo project is organized as a collection of outlines, which are basically a hierarchical and collapsible tree of things (nodes) that go into a program. Some nodes contain fragments of source code, others documentation, others mainly organize further child nodes. Selecting a node within the tree pane displays the code or content associated with it in the editor pane. For example, a Python module will usually be a node, which contains a number of child nodes for its classes. Each class node might contain some documentation, and also a collection of method nodes. In effect, this organization of nodes builds folding deeply into the editing environment; but a node is more than just a fold point -- for example, nodes can be cloned, so that a view of the same node appears at multiple relevant locations within a larger project.

Creating actual source code out of a Leo project, or importing it thereto, is done by tangling and untangling the project. For example, Leo does a good job of automatically generating an outline from existing .py files. You may also, of course, start a Leo project from scratch, and specify what gets written to which files (and in what languages, code or documentation). Directives within nodes specify both what gets written when untangled, and also the appearance and behavior of sections.

As editors go, the content pane of Leo is on par with IDLE. The interactive Python shell in Leo, in fact, appears to be borrowed from IDLE directly. But Leo is not really best thought of in terms of traditional code editing -- rather it is an organizer, project workspace, and structured development environment. Per Knuth's vision, the actual code is almost peripheral.

I have, in truth, not really used Leo enough to fully get the style of development it promotes. I have an inkling that it might be genuinely useful for a wide variety of projects, both applications and documentation -- but it takes some work to adapt to the style of Leo. Still, many of my readers swear by it.

The OS X native choice

MacPython comes with an IDE called, straightforwardly enough, "PythonIDE." I also looked at this briefly in my last IDE roundup some two and a half years back, and much remains the same. Most certainly, PythonIDE feels a whole lot more like you are working on MacOS than do the Tk or Swing interfaces of the other tools I look at in this installment. Other than its native feel, however, PythonIDE feels much simpler -- even cruder -- than the others. And of course, even though code you write in PythonIDE ports transfers fine to Linux desktops, the environment itself does not.

For a start, PythonIDE lacks syntax highlighting in its editor, which I have grown accustomed to. It does have good Python awareness in indentation behavior, block indent/dedent, class/function browser (this hidden next to the horizontal scroll bar). The object browser is interesting, and somewhat unique. Rather than simply giving you a collapsible tree view of code, the object browser gives you a live representation of the objects themselves -- even of the importable modules in your PYTHONPATH. The last is an interesting way to explore support modules, whether standard or third-party (and can give you some details beyond what makes it to documentation).

For the most part, PythonIDE is similar to IDLE or jEdit in organization. You get an editor along with an interactive shell. Code and execution output appears in one or the other, and you can interactively copy back and forth. PythonIDE also uses a separate "output" window, which is probably a better design than IDLE's doubling up of the interactive shell window. But the editor remains basic in many ways -- not even using regular expressions in the search dialog, for example.

However, two places where PythonIDE stands out are in its debugger and profiler. IDLE has a debugger (jEdit/Jython does not), but PythonIDE's feels nicer to use. The profiler remains unique to PythonIDE, although you can, of course, achieve the effect more awkwardly using the profile and timeit modules.