Adam DePrince wrote: > Instead of worrying about how to appropriately cripple CPython to > provide a secure sandbox, perhaps we should be reaching towards PyPy for > this answer?
This thought might be relevant to another issue that came to my mind recently. It concerns using Python as an extension language for an application. If you have an application implemented in some traditional way such as compiled C or C++, embedding a Python interpreter in it is a nice way of providing users with a nice playground they can program in without fear of messing up the main application, which is "hard coded" and able to protect itself from most things that the Python code can do. But what happens if the application itself is implemented in Python? Then it's very difficult to keep a separation between the application proper and the scripting environment. So I think this is another, distinct use case for wanting a "nested" Python environment. Here the goal isn't to protect against a malicious user, since the user running the application and the user doing the scripting are the same person. Rather, it's just to reduce the likelihood of accidentally messing things up, and to present the user with a much simpler programming environment than the whole application. So the requirements are far less strict, and if there were a few holes in places, it wouldn't matter so much. -- Greg _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
