From: Mark P. <li...@ma...> - 2004-10-22 00:56:06
|
I spent some time looking through the source code to understand whats happening and have taken the bits I need from PythonInterpreter to give me a light-weight way to get globals: static { PySystemState.initialize(); PySystemState systemState = Py.getSystemState(); if (systemState == null) { systemState = new PySystemState(); } Py.setSystemState(systemState); } public PyDictionary getGlobals(String s) { PyModule module = new PyModule("main", new PyDictionary()); PyObject locals = module.__dict__; Py.exec(Py.compile_flags(s, "<string>", "exec", null), locals, locals); return (PyDictionary) locals; } I believe in my case sharing system state is fine; however Jim you may be able to leverage this to make sure it gets a new PySystemState when it needs to - dont know if that was why you couldn't share globals. Interesting when you do from java.util import * it sticks in all 64 classes from that package into individual keys of the dictionary - wasn't aware it did that, I thought it might have done something more clever with lazy lookup because it was *. Thanks for the help, and any further pointers would be great appreciated :) Mark Samuele Pedroni wrote: > Samuele Pedroni wrote: > >> Mark Proctor wrote: >> >>> Yes if I could pass the imports via the dict that would be great >>> then I can continue to use Py.runCode - which I assume is cheaper >>> than having lots of PythonInterpretors - anyone care to explain the >>> inner workings here? I know how to bind a single class type via the >>> dict but not how to do it for statements like "from module import *" >>> >> >> if I understand you have this situation, various instances of >> >> <imports> >> suite with imports? >> </imports> >> >> <functions> >> suite with func defs >> </functions> >> >> <condition> >> expr >> </contidtion> >> >> <consequence> >> suite >> </consequence> >> >> you execute imports and functions in a dict, you store it away, >> >> then you compile condition and consequence to code and store those too, >> >> and when necessary you execute them passing the parameters as locals and >> the dict populated in the first step as globals. > > > an alternative for condition and consequence is to transform their > code to functions defs if you know the involved parameter names: > > def _cond(parm0,...): > return <contion-expr> > > def _cons(parm0,...): > <consequence-suite> > > you would execute this code with empty locals and the shared globals, > then extract from the locals _cond and _cons and invoke them using the > PyObject.__call__ family of methods. > |