Before anyone gets too fired up about this, there are two major limitations:
1. Python code will only be executed from trusted sources (i.e., chrome loaded from the local filesystem). This means that you'll need to get users to download and install an extension to use your Python script code, rather than simply including it inline in a page on your server.
2. Because the extension bundles its own Python runtime, it has to be built and packaged separately for every architecture target. Right now, that means no 64-bit platforms, BSD, etc. -- so cross-platform compatibility is probably no better than Flash at the moment.
That being said, having yet another development language on the client for rich web applications is pretty cool. I can imagine all kinds of useful projects that could capitalize on Python's strong libraries. Hooking into native libraries using Python (either via the extension API or ctypes) is also a lot easier than writing an XPCOM wrapper.
I don't really see this as being a boon for web developers, but for those who write or use Firefox extensions. That does include certain websites, but those are only the sites that are already utilizing a Firefox extension, anyways (e.g. del.icio.us, rememberthemilk). I would personally much rather hack up a Firefox extension in Python than to try to do it in Firefox's standard plugin architecture thingamajig (Javascript/CSS/voodoo/???).
2. Because the extension bundles its own Python runtime, it has to be built and packaged separately for every architecture target. Right now, that means no 64-bit platforms, BSD, etc. -- so cross-platform compatibility is probably no better than Flash at the moment.
Just be sure we're clear, this comment describes the pyxpcomext extension itself, right? Surely more versions will be coming soon to any platforms supported by Python. If you are building an extension that utilizes this Python-Mozilla API, this is all transparent to you, and packaging separate builds is a non-issue.
I would personally much rather hack up a Firefox extension in Python than to try to do it in Firefox's standard plugin architecture thingamajig (Javascript/CSS/voodoo/???).
You'll still need to do "CSS/voodoo/???" to integrate your extension to the Firefox UI.
What you get to do is to use Python instead of JavaScript (a matter of taste), and you get access to Python libraries, which cover desktop-side computing much better than JS.
This is like ActiveX but managed and therefore with only 1% of the original brain deadness of the ActiveX design.
Note: I would still be concerned about security with this. Even though python scripts can only be executed from trusted locations, quite a few web users have no idea what that is.
The most amazing thing is that you can use real Python inside web pages instead of JavaScript (only for your Gecko/Mozilla apps not for all the web for obvious security reasons).
Very very nice. I would like it better if it used the native python environment already floating around in the system instead but that would probably make compatibility a nightmare. Still, kudos to the ones who wrote this.
Unfortunately it didn't work:
Alex Badea has actually made a pyxpcom extension for Firefox3, but it is a somewhat different approach as it relies on a matching python being installed on the system and other extensions using pyxpcom may not get registered :(
http://vamposdecampos.googlepages.com/pyxpcom
To my knowledge IronPython cannot easily call python extensions written in C/C++. So going with IronPython means using Microsoft's .NET libraries (or the mono clones) for many tasks, just as using JVM based languages means falling back to Java libraries as a replacement for those Python/Ruby libraries that haven't been reimplemented on top of the VM.
Python has a huge number of libraries and it keeps growing. I don't think the attempt to reimplement everything on top of .NET/Java is going to succeed. The people who maintain these libraries are not going to do it so where's the army of people who will take on such an incredibly boring task? I hope, one day, C/C++ libraries will be conveniently accessible from the VMs.
The only viable alternative would be to implement all Python libraries exclusively in Python. That's something that current maintainers of C/C++ extensions might consider doing. But Python would have to be much faster for this to work.
* does not include video or audio support. Videos just ask you to download Silverlight.
* not packaged
* not presented by Microsoft to users who need a plugin when they access Silverlight content. When you visit a Silverlight page, a 'Download Silverlight' button takes you to Microsoft. The Microsoft page gives another 'Download Silverlight' button that tells users their 'platform may not be supported'. Clicking them gives no download and returns back to the same Microsoft page ad infinitum.
Well, that might be. But in this context I wasn't even talking about running full Silverlight apps, just having a decent browser-independent, cross-platform Python runtime.
1. Python code will only be executed from trusted sources (i.e., chrome loaded from the local filesystem). This means that you'll need to get users to download and install an extension to use your Python script code, rather than simply including it inline in a page on your server.
2. Because the extension bundles its own Python runtime, it has to be built and packaged separately for every architecture target. Right now, that means no 64-bit platforms, BSD, etc. -- so cross-platform compatibility is probably no better than Flash at the moment.
That being said, having yet another development language on the client for rich web applications is pretty cool. I can imagine all kinds of useful projects that could capitalize on Python's strong libraries. Hooking into native libraries using Python (either via the extension API or ctypes) is also a lot easier than writing an XPCOM wrapper.