Python as client-side browser script language

[Paul Boddie]

Greg Ewing <greg at cosc.canterbury.ac.nz> wrote in message news:<3g79esFb0jkrU1 at individual.net>...
> 
> If the DOM objects are implemented as built-in Python
> types, there shouldn't be any difficulty with that.
> Python objects have complete control over which attributes
> can be read or written by Python code.
> 
> That, together with restricting what the open() function
> can do, ought to provide a pretty good sandbox.

Is that really enough, though? Previous discussions [1] suggested that
the problem was pretty extensive, and the topic has been proposed [2]
for the Summer of Code thing [3], although $4500 may not be a lavish
enough amount if the work requires a complete overhaul of CPython.

But on the subject of Python as a browser *extension* language where
you download extensions from trusted sources and run them from the
browser, PyKDE can be used with Konqueror to explore this area,
although it does require a very recent PyKDE to work fully - see the
kpartplugins on this page for more information:

http://www.boddie.org.uk/david/Projects/Python/KDE/index.html

It would also be great to unify Konqueror and Mozilla in some way by
providing a common API for Python extensions - this could be done by
wrapping Mozilla's DOM, presumably exposed via PyXPCOM [4], in a way
similar to qtxmldom [5], and then making sure the boilerplate
(initialising the extension, getting initial references to browser
documents) is separated out from the actual extension code.

Paul

[1] http://www.amk.ca/python/howto/rexec/rexec.html
[2] http://wiki.python.org/moin/RestrictedExecution
[3] http://code.google.com/summerofcode.html
[4] http://www.mozilla.org/catalog/architecture/xpcom/pyxpcom/
[5] http://www.python.org/pypi/qtxmldom