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:
- PyXPCOM uses XPCOM as its means of communication between Python and the Mozilla platform. Unfortunately, XPCOM is super heavyweight and it’s a particularly difficult hurdle to get through when all you really want is for two very dynamic languages to communicate with each other. For instance, Ubiquity itself implements very few XPCOM interfaces, and most of its functionality is exposed through JS Modules; jsbridge allows us to access these JS Modules directly, while accessing them from PyXPCOM would require us to create verbose XPCOM wrappers around them—a particularly egregious amount of work when you think about how similar JavaScript and Python are.
- 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.
My name is Atul Varma, and I'm the co-founder of a small Chicago company called 
I had the same issue when I started developing a Cross-cloud control application. I could embed Python into it but it was a waste. I turned the whole thing into a Python module and open sourced it instead. For those that are interested, it is at http://code.google.com/p/cloudwizard/
For the Maavis Firefox extensions I used a fork of the Outfox js/xul/Python connectivity platform (simple JSON message passing). I skipped the JS as is all XUL. This works well enough for simple purposes.
I chose to package up python with py2exe but take on board your Python as platform thoughts. In my case ease of installation was important and py2exe takes care of all the dependent modules as well plus avoids side-by-sdie python version issues on Windows (only one is the default).
http://www.assembla.com/wiki/show/maavis
http://code.google.com/p/outfox/
I thought I’d comment on a couple points. Not trying to be an XPCOM fanboy, and jsbridge looks very interesting, just relating my experience with PyXPCOM.
You don’t need to write xpcom wrappers to use js objects as xpcom objects unless…the other language needs to createInstance/getService to get the object. If you want to pass a js object from chrome to a pyxpcom instance (in fact any xpcom instance), you only need to be sure your js class implements the functions defined in IDL for the interface you are calling. jsconnect handles the magic for you. We do this all the time in Komodo. Python works similarly, you don’t need to createInstance on a python object to pass it through xpcom, so long as the com_interface is defined in the class. That helps to reduce overhead on the python side.
XPCOM is really not that slow (it’s not blazing fast either) unless you are iterating over something across XPCOM boundaries. We often unwrap the object if it’s a python xpcom object, or rearchitect a bit to avoid those situations. At this point, when we have performance issues, it’s almost never an XPCOM issue.
Using the system python is fine so long as you are not involving binary components or the user builds the components on their system. Mozilla is built with UCS2, linux distros vary between UCS2 and UCS4 for at least the python build. That can cause havoc to say the least. The other issue of course is, the user upgrading some module that then breaks your application.
Small or non-binary based projects may not run into these issues, but they are significant for larger projects that do binary distros. For example, if PyXPCOM were part of Firefox, IMO Firefox would be distributing/embeding python to avoid these issues. Firefox actually has lots of home-grown or embeded code (expat is an example) rather than relying on system provided code to avoid dependencies on external systems.