Ka-Ping Yee writes:
A. The interpreter will not crash no matter what Python code it is given to execute.
Why? We don't want it to crash the embedding app (which might be another python interpreter), but if the sandboxed interpreter itself crashes, is that so bad? The embedding app should just act as though that interpreter exited, possibly with a status code.
B. Python programs running in different interpreters embedded in the same process cannot communicate with each other.
Why not? Can't eavesdrop, yes. Can't force a connection, so that the other interpreter is free to ignore them. Maybe even make it lockable, like sockets -- but it isn't something worth promising.
C. Python programs running in different interpreters embedded in the same process cannot access each other's Python objects.
Note that Brett's assumption of shared extension modules violates this -- but I'm not sure why he needs to assume that. (Because of the init-only-once semantics, I'm not even sure it is a good idea to share them.)
D. A given piece of Python code cannot access or communicate with certain Python objects in the same interpreter.
Why not? Is this just a way of allowing lightweight subinterpreters? Or do you really mean that they can't replace or modify certain objects, such as the permission-controlling code?
E. A given piece of Python code can access only a limited set of Python objects in the same interpreter.
Does this include objects it creates? Or are you just saying that it will behave as if its builtins were segregated, and not see changes made by another interpreter? -jJ