Python notes 4/30/07

This week I've been looking at Python development systems, window/graphics systems, and have written a small program for displaying FITS images. I think that now I have most of the pieces necessary for writing larger and more complicated programs, potentially those similar to Scientist's Workbench or FITSFlow.

Development systems

Python programs can be developed using just a simple text editor (like BBEdit) and the Unix command line. However, many people feel more comfortable with an Integrated Development Environment (IDE). Python comes with a simple one called IDLE, which doesn't do very much, and isn't pretty (not Mac native). However, there are several free, and not-free, native Python development systems available for the Mac. For a listing of some, see the Python Wiki. Which one you use is pretty much a matter of personal preference, although some of them do have potentially useful features like code analysis and debugging. One minimal but free Python editor is TextWrangler, the successor to BBEdit:

Another free editor is ScrIDE:

One not-free system is Wing, which comes in 2 flavors: personal ($35), and professional ($179). This system has both code analysis and debugging, if you think you need them. However, the Mac version is not native, and runs under X-Windows. It looks reasonably nice (probably GTK widgets), but is clunky due to X. Personally, I wouldn't pay for anything that isn't Mac-native (like IDL):

My choice has been to go with XCode, since it's free, native, and I've been using it for ObjC. It doesn't do much Python-specific stuff, but it's very configurable, and makes a good general multi-file project manager:

Window/graphics systems

Although there are several free and non-free window/widget/graphics systems for Python, I've concentrated on looking at the 3 main (and free) ones: Tk, wxPython, and PyGTK. Several Tk examples are shown in last week's notes. Tk comes with Python, and is probably good enough to do most programs. The best system appears to be PyGTK, which is a Python wrap of the GTK+ library (GIMP/Gnome Toolkit), which forms the basis of Gnome Unix systems. However, this system is difficult to set up, and has lots of prerequisite libraries to compile/install. Also, it is not native on the Mac, and runs under X:

The system I've chosen to use is wxPython. It is free, and native on the Mac. It is between Tk and GTK in terms of complexity and beauty, and appears to be adequate for most GUI needs. Actually, it is a Python wrap of a Windows C++ library. Luckily I've done Windows C++ GUI programming before, so the syntax and operation are familiar to me. There are also a couple of GUI-builder apps based on wxPython (similar to Interface Builder) which claim to improve the tasks of interface design:

There is also a pretty good book about wxPython called wxPython in Action. I strongly recommend getting this, especially if you've never done event-driven programming before:

FITS image display

I've written a simple program that reads and displays FITS files: plotfits.py

Take a look at this to see what Python and wxPython code looks like. To run this on your system, you will need Python 2.4, numpy, pyfits, and wx. The first three are availabe from last week's page. This program essentially duplicates the functionality of my Cocoa plotfits program, but is much shorter. It can be multiply-launched from the Unix command line:

Here is a version of fits2image which creates the RGB buffer in a more Python-like way, and is much faster than the previous program.

Future work

Although all the pieces may be present, there is still the little matter of actually doing the work, either for SWB or for any other program like FITSFlow. Again I would suggest trying something non-trivial in May, as a working test of both Python and wx. One caveat to be aware of is that wx is an application framework, somewhat similar to the old MacApp. Once started, it takes control of the program and essentially makes callbacks to Python to handle system and user events. Therefore it may not be possible to return to the Python command line while a wx program is running (once a wx.App has been created). In order to create an interactive windowing system from Python (e.g. in which one could call functions to display graphs and images like other Python functions, and then continue working with data from the Python command line) it may be necessary to use a somewhat independent programming strategy similar to that employed by DS9. I can envision a wx graphics server running in parallel with the Python interpreter (actually, under another copy of the interpreter) and which communicates with the interactive Python session via a pipe or socket. That way commands and data sent to the wx server could be handled completely within the wx application architecture, and would not interfere with the other Python session. It shouldn't be too much trouble to create a simple server, and it would have the advantage that all window and graphics operations would be scriptable right from the start. This might be a good test task for next month.

ŠSky Coyote 2007