[zo1]

A non-issue... All of those things/features you mention as problems could simply be removed from the python interpreter included with the browser.

Will some of it leak through? Possibly. Does that mean we should do it or try? Of course not.

[Alupis]

This is a straw-man argument. You are not understanding the fundamentals of web safety and the design decisions behind ECMAScript and derivatives. Put the fanboyism down (i love python just as much as the next guy).

if it can be removed (features, api's, etc), then it can be added back in (maliciously or not) or hooked into via a system runtime or a program installed on the system. If it's just not there at all (the api's nor the facility for the api's), then it can't be added. that is really the boiled down version.

every other language that has tried to be a web language without being explicitly designed as a web language has failed. why do you think python would be any different? because python is just so awesome?

and to rebut your point in the other thread, i have stated explicitly the things that make javascript "safer" -- you have just chosen to ignore them or brush it off. I'll say it again -- javascript does not have the api's nor capabilities to make direct system calls. system calls are filesystem actions, threading actions, process manipulation, executing arbitrary code, writing to different outputs, manipulating memory, etc. these are all considered highly dangerous to run from a browser.

[andreasvc]

There is a simple strategy to make a sandboxed Python runtime. 1) remove anything from the standard library that affects files or system stuff. 2) disallow anything but Pure python libraries.

Arbitrary system calls can only come from either the standard library or an extension module in C, and these are ruled out by step 1 and 2. Your argument about adding things back in or hooking into other runtimes is unsubstantiated; ruling out such things is the very goal of making a sandbox.