Message12942

At first I was surprised by:

>>> eval("__name__")
'__main__'
>>> eval("__name__",{})
'__builtin__'

but of course in the first eval() the global dictionary is inherited from the REPL, and so contains a binding for __name__, while in the second case the global dictionary is empty, and __name__ is found in the __builtins__ module. There may be a clue here for how our JSR-223 implementation should behave.

To judge by org.python.jsr223.ScriptEngineTest.testThreadLocalBindings() and the discussion on #1426, the use case is:
1. Get a "Python" engine e from the manager.
2. Optionally use e with one or more calls e.eval(script).
3. Get an empty Bindings object b (essentially an empty dictionary) and optionally populate it.
4. Call the engine one or more calls e.eval(script, b).

b acts as the module namespace (globals) for all eval() calls that mention it. You can use as many distinct name spaces as you like with one engine. The engine has one PySystemState, with its sys.modules list, but the default context, and each b, contains a distinct module state.

These states might be used from different threads, but they don't have to be. I still don't quite get the idea behind namespace juggling being done using a ThreadLocal, why a change of Bindings isn't enough. It's also bugging me that the calls involved are setLocals() and getLocals(), while it is clearly interp.globals that they manipulate (sometimes).


I think it reasonable that the calls at step 2 should find an environment like the REPL, with __name__ set, while the calls at step 4 should see an empty dictionary, by analogy with eval(). This ought o be possible, but I'm finding the thread-based juggling obscures the logic.