Re: [Jython-dev] imports with parser type eval

[Mark P. <li...@ma...>]

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.
>