Cocoa for your Python?01/31/2002
I am suffering from Mac lust. I feel irresistably drawn to the new iMac. That lovely TFT monitor has cast a spell on me. Yet I still have wits enough to wonder, what is the state of Python and OS X?
On OS X, you have three, actually four Python choices now. The most obvious Python interpreter, MacPython, can be installed either as a classic application -- OS 9.1 in a virtual machine on OS X -- or as a Carbon application. Carbon is a runtime environment offering a streamlined Apple Mac API, designed to help programmers migrate from Mac OS 9 to Mac OS X. With Darwin, the BSD Unix core of the new OS X, you can compile Python from Unix sources. Finally, there's Jython, the 100% Java implementation of Python. If you're feeling lost, you might want to review Apple's overview of the OS X system architecture.
Many people stick with MacPython Classic. The big reason not to install MacPython as a Carbon application has been Tk. Tk wasn't Carbon, which puts it in the Classic ghetto. If you installed Python as a Carbon application, you lost Tk. Recently Tk has gone Carbon and as soon as the bugs are worked out, it should work with a Carbon Python installation. With Tk available, future versions of MacPython will likely support Carbon only and will merge the existing MacPython with Unix Python.
Getting to Tk is important, but on OS X the bigger question is can you get to Cocoa? Cocoa -- a set of development frameworks for OS X written in Objective C and available to Java applications through a Java-Objective C bridge -- has Java programmers drooling. Cocoa is what you want if you are going to create OS X applications. As a Python person, I want Cocoa too.
Steven Majewski, a contributor to the original MacPython port, is working on getting to Cocoa from Python. Majewski resurrected the old pyobjc project. Originally written for the Next, but abandoned in 1998, pyobjc's code lay dormant until last year, when Majewski picked it up. The pyobjc module is essentially a Python to Objective-C bridge. It works about the same way the Java bridge works. For speed, pyobjc handles the translation of some basic objects like arrays and strings and relies on NSProxy for the rest. NSProxy is a distributed object class in Objective-C that stands in for foreign objects or objects that don't exist yet. Working through the proxy, Python objects can connect to Objective-C objects and vice versa.
Because the Cocoa framework is an updated version of the Next programming framework, pyobjc mostly works with Cocoa, too But it needs some updating. Recent changes in both Python and ObjectiveC open many new possibilities. Until recently, proxied Objective-C classes were available as Python objects, but they were not Python classes. This meant you couldn't subclass them. Previously pyobjc created delegate objects, which you could subclass, but this code is not currently working with Mac OS X. Python's new type-class unification, however, should make it possible for Python 2.2 classes to inherit from proxied Objective-C classes. Some new introspection code in Mac OS X's Objective-C should also make it possible to build dictionaries of proxied methods which could be used instead of testing each method on-the-fly. Combined with Python 2.2's metaclasses, the introspection methods could be used to coordinate different lookup methods, caching a dictionary of method information as it's used.
The theory is promising, but it may be a while before we see all these improvements. As it stands now, if you are using Python 2.1 and the current pyobjc, you can script Cocoa objects procedurally, which kind of works, but is far from the real programming power that would make Python shine on Mac OS X. Most MacPython programmers will want to stick with Carbon or classic for now, or use something like Tk.
If you can program Cocoa with Java, how about Jython? Well, yes, kind of. You program Cocoa with Java using a Java to Objective-C bridge, which coordinates translations between the two. But Jython itself is a kind of Python to Java bridge. So you have two bridges and a lot of magic going on: translating Python objects to Java objects to Objective-C and back again. That's a long commute and a ton of overhead. For example, Jython knows about Java strings, and so Java strings are automatically converted, you can use them in Jython just like Python strings. But Jython doesn't know about Cocoa's NSstrings. So they don't get translated. This holds true for all your basic objects. There are ways to work with them, but it adds complexity.
As Steven Majewski tells me, "there are a lot of things that almost work." Cocoa for Python is still on the frontier, available to the adventurous. The more traditional toolkits in Carbon or Classic are much more accessable. The future, however, looks bright. There's no compelling Python-specific reason to buy a Mac but no large disincentive for Pythoneers either. Sometimes the frontier is just the place to stake your claim to fame and fortune.
Stephen Figgins administrates Linux servers for Sunflower Broadband, a cable company.
Read more Python News columns.
Return to the Python DevCenter.