Nevertheless, there is necessarily an impedance mismatch between the runtime models — when passing objects to Cocoa, the bridge must convert the object from the dynamic language’s runtime to an Objective-C object derived from NSObject, and vice versa. This introduces a certain amount of inefficiency, which is not normally a big problem, but it would be desirable to avoid it.

Now, over the last few months, I’ve seen a variety of projects to do this by using the Objective-C 2.0 runtime to implement the object model for the dynamic language. In other words, objects in the dynamic language are subclasses of NSObject and no conversion is necessary.

These range from the venerable F-Script, which is even closer to Smalltalk than Objective-C, to Tim Burks’ original language Nu, which uses a Lisp-like syntax. I believe I’ve seen a reference to a JavaScript implementation as well, but I can’t seem to find it now.

The project that seems to be getting the most buzz in the Mac community right now is MacRuby, a port of Ruby 1.9 done by the developer of RubyCocoa (who is also an Apple employee). There was even a article about it featured on the Apple developer site recently.

Conspicuous by its absence from this list is my preferred dynamic language Python. I would love to see an implementation of Python hosted on the Objective-C runtime. I’ve always felt Python’s language model was a good match for Cocoa (of course, PyObjC not only predates BridgeSupport but even Cocoa itself, going back to the days of NextStep), and I’m personally more familiar with it than Ruby or other dynamic languages. So it seems like a logical step to take.

This project couldn’t be called MacPython, because that name has already been used to denote the Mac port of Python. For now I’m calling it “OCPython”, but I’m certainly open to a cleverer name (especially if there’s one that can riff on IronPython; unfortunately the element most associated with Mac OS X is Carbon, which is entirely wrong for this project).

I’ve been thinking about which version of Python to use as a jumping-off point; originally I was leaning towards 2.5 because it’s the version shipped with Leopard, but now I’m persuaded by Bill Bumgarner’s comment to use 3.0 and take advantage of the revised, less crufty implementation. (This is based on the stated goal of the 3.0 development project; I haven’t actually looked at the source code yet.)

I wish I could say I’m prepared to get the project off the ground myself, but right now I’m between jobs, as they say, and given the current financial situation I’m actively looking for full-time employment and can’t dedicate much time to something that won’t bring in any revenue. (Of course, if anyone out there would like to fund development of OCPython, contact me immediately.)

In theory, Python ought to do better, lacking all those silly end statements cluttering up the screen. But in practice, when I look at Python code I find my eyes distracted by a barrage of underscores and double-quote marks. Typography is an important component of human communication, and Ruby’s, on balance, is cleaner.

John Gruber concurs:

Now that I think about, those underscores and extra quotes are exactly why Python does not appeal to me. I find Python’s indentation-as-block rule to be quite elegant, but its use of punctuation feels clumsy.

As a Python programmer (but not a Ruby programmer), I have to say:

Huh?

I respect both Bray and Gruber, but I don’t see their point. At all.

When I look at my Python code, I see underscores in two contexts. The first is in the names of “special” methods and attributes. In practice for me, this is largely limited to __init__, since I rarely need to overload operators. (And this syntax makes such identifiers stand out as “special”. Who’s to say that this is less attractive than Ruby’s use of $ to mark global variables? Are underscores uglier than dollar signs?)

The second, more common use of underscores in my code is in long Cocoa method names, because by convention in PyObjC they replace the colons in the Objective-C selectors. Those underscores are generally acknowledged as ugly by the PyObjC community, but accepted as a necessary evil. I suspect Tim Bray is not writing PyObjC code. (Maybe he’s writing more special operators than I am.)

As for quote marks (single or double), the only “barrages” I can think of are in multi-line string literals, which are frequently used as documentation strings (or comments, effectively). I suppose this criticism might come from the common use of string literals as symbols — e.g., as keys in dictionaries (hash tables) — where Ruby has an actual symbol type, whose syntax is borrowed from Lisp keywords (a prefixed colon).

Whereas if one wanted to criticize a language for “clumsy” punctuation, one might point to any of the fourteen-odd uses of non-alphanumeric symbols in Ruby found here: marking different kinds of variables with $, @, @@, and &; four kinds of “quoting mechanisms” with %X{..}; etc. (Is that Perl I hear calling?)

Perhaps that’s why neither Bray nor Gruber commented on the controversial use of @ in Python to mark the user of a decorator function.

So I have to say I just don’t get it. To each his own, I guess. I see that Ruby is getting a lot of buzz these days, in large part because of the success of Rails, and that’s fine; if I had to throw together a quick web application I might investigate Rails too. Perhaps it’s just that I came to Python first and don’t really know Ruby very well.

Still, to me, saying Ruby’s use of punctuation is “cleaner” than Python’s is (to paraphrase Gruber) like criticizing the iPod because it doesn’t come in white…

To use it, download it and move it to your ~/Library/Services folder. At the moment you will probably have to log out and log in again to update your Services menu. If I get motivated I’ll build an installer, someday. (Unlikely since I’ve only spent about an hour on this, most of which was taken up building a universal binary for PyObjC. While it is true that PyObjC rocks, its universalness is still a little, uh, rocky.)