OCPython, anyone?

As dynamic scripting languages become more widely used, many developers are interested in using them to write “native” Mac OS X software, rather than having to learn Objective-C (which, of course, is a dynamic language in its own right). And in fact it is often possible to do so, using Apple’s BridgeSupport to generate the necessary metadata. Apple explicitly supports bridges for Ruby (RubyCocoa) and Python (PyObjC).

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

This entry was posted in Apple, Macintosh, Python. Bookmark the permalink.

6 Responses to OCPython, anyone?

  1. Tim Burks says:

    Hi Russ,

    The Apple employee you mentioned is Laurent Sansonetti, and although he’s contributed significantly to RubyCocoa, he didn’t get involved until the project was nearly five years old — RubyCocoa was first released in 2001 by Hisakuni Fujimoto.

    The path that took me to Nu started with Python and PyObjC, and frankly I think that Python isn’t as good a match for Objective-C as Ruby is; this is primarily because in Ruby, everything is an object, and that means that under the covers, every Ruby (and now Nu) object can be implemented as an Objective-C object. Perhaps that’s changed in Python 3000, but I also feel that Python comes with a lot of baggage (aka batteries) that you’ll want to throw away and replace with the libraries and components that you’ll find in the Objective-C world.

    But if you want this, let me encourage you to get started; there are lots of people blogging about things they wish someone else would do. Be the one who makes them happen! :-)

  2. Russell Finn says:

    Hi, Tim; thanks for checking in.

    Yes, it was Laurent I was thinking of. He was on stage at the WWDC session in 2006 where Apple committed to supporting Python and Ruby development in Leopard and beyond, and I remembered him being introduced as “the developer of RubyCocoa”, so I assumed he’d originated it. I’m not really involved with the Ruby community, so I didn’t know any better.

    As for Python vs. Ruby — I already know Python; I haven’t learned Ruby. Everything is an object under the covers in Python, too; you may not be able to say 3.__add__(4) (which is the sort of thing that people who say “everything is an object” often look for), but that’s just an issue in the parser. (And of course ” “.join(words) is a common Python idiom.)

    So I’m confident that Python objects can be implemented as Objective-C objects. Plus we have IronPython and Jython as examples of porting Python to other object models — not that I’m particularly eager to dig into either of those code bases.

    Most of the “batteries” included in Python (i.e. library modules) are implemented in Python itself, so I don’t see that as an obstacle. Of course I expect most users of OCPython will primarily use the Cocoa frameworks — but it’ll be convenient to have “batteries” around too (just as it is with PyObjC).

    Thanks for the encouragement. Now I just need to find time and money. Or perhaps I should just investigate Nu some more. I went to MIT, so Lisp syntax doesn’t scare me. :-)

  3. I wonder if a ‘lower cost’ approach might be to work on an Objective C backend for PyPy. The Python front-end is already implemented so by emitting Objective C on the backend a lot of the work is already done.

    Of course PyPy backends are quite general – so it may not be much less work, but you will find others willing to help and there are several examples to work from (plus most of the backend can be written in Python – or at least RPython I guess).

  4. fijal says:

    Details about writing a backend for PyPy:

    • It’s full python, only interpreter is written in RPython

    • It’s definitely less effort than writing Python interpreter. Details are rather hairy :-)

  5. Russell Finn says:

    Hi, Michael and Maciej. This topic is certainly bringing visitors to my little corner of the blogosphere.

    PyPy might well be an interesting approach. The issue for me is that quite frankly I know next to nothing about PyPy; whereas I’m somewhat familiar with the internals of CPython — in a previous job I embedded the Python interpreter into a larger software system and exposed its internal data model through the extension mechanism. So I would personally be inclined to approach the problem from that viewpoint, in the absence of more knowledge about PyPy. (I have to say that my admittedly brief investigation of the PyPy website this evening didn’t prove especially illuminating.)

    Still, if someone wanted to approach the problem by using PyPy, more power to them.

  6. Russell Finn says:

    For completeness: The JavaScript implementation I was thinking of is apparently JSCocoa, which is actually a JavaScript-to-Cocoa bridge (like PyObjC) and not a re implementation of JavaScript as I had previously implied.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>