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.
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
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:
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.
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