Yesterday Tempura left a good question as a comment on my blog post concerning Ubiquity’s experimental support for Python:
What about http://pyxpcomext.mozdev.org ? They bring Python in an xpi for all major plattforms, without the need of an local installed interpreter.
Using PyXPCOM was actually a potential option we had considered, but we ended up going with jsbridge for a number of reasons:
- One advantage of using the local system's Python installation is that we inherit whatever packages come with it, which means that on OS X 10.5, for instance, we automatically get access to Python's bindings to Objective C and Cocoa, whereas with PyXPCOM we really have to manage the user's distribution manually. It could similarly be said that PyXPCOM takes an embedding approach, while jsbridge takes an extending approach; a very good analysis between these two approaches has been written by Glyph Lefkowitz here.
- In regards to Windows, putting a distribution of Python on the end-users system that any other application can leverage is a good thing—much better than requiring the user to download a big package and then only allowing Firefox to use it. This gets into the idea of Python as Platform that I've written about before.
- In regards to OS X and Linux, using the pre-existing installation of Python is obviously nice because it doesn't require the end-user to download anything (aside from mozrunner and jsbridge, which are pretty small).
- jsbridge has no binary components, which makes it a lot easier to maintain and experiment with than PyXPCOM, which is difficult to compile and extend.
PyXPCOM is definitely useful for a lot of things, though—for instance, manipulating the DOM of a page—so I think there’s still some things we can leverage there. And jsbridge certainly presents its own hurdles and limitations, too, but hopefully this post sheds some light on the thought processes that went into deciding which mechanism to use.