Greg Ewing <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > > 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 -- http://mail.python.org/mailman/listinfo/python-list
