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.

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

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

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

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.

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!