jython-dev

[Jython-dev] work in progress notes

[Samuele P. <pe...@in...>]

Hi.

[Finn]
> Update of /cvsroot/jython/jython/Tools/jythonc
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv28475
>
> Modified Files:
> compile.py SimpleCompiler.py
> Log Message:
> A small hack to fix bug 123627. This does not solve the dynamic
> issues with finding modules in __path__, but it works in the
> situations where the dotted package names matches the directory
> structure.
Very good. I don't think it makes very much sense too support the dynamic
__path__ values in jythonc,
in python it seems to me they are supposed to be set depending on something
only known at runtime.
To use their values at compilation time seems not so much useful.
I'm not sure of that: should not also SimpleCompiler._getnames be modified
to support pkg rel imports.

*****
I'm working on the cache fix, as I wrote I would like to write different
caches that are chosen depending on java 1.1/2 env
and options from the config files.
I have noticed that in general Options.setFromRegistry is called before the
first PyJavaClass.lookup, which is good, but for example in the embedding
case (e.g. SimpleEmbedded.java) when PythonInterpreter ctr is called without
first issueing a
Py.initialize, PyJavaClass.lookup is called before Options.setFromRegistry.
Should we state that Py.initialize should be issued before using any other
part of runtime. Or someone can propose
a workaround. I should be able to know the value of the newly introduced
cache options in PyJavaClass.lookup
in order to construct the right/requested kind of cache.
Hints are welcome.

regards, Samuele.

Re: [Jython-dev] work in progress notes

[<bc...@wo...>]

[Samuele]

>I'm working on the cache fix, as I wrote I would like to write different
>caches that are chosen depending on java 1.1/2 env
>and options from the config files.
>I have noticed that in general Options.setFromRegistry is called before the
>first PyJavaClass.lookup, which is good, but for example in the embedding
>case (e.g. SimpleEmbedded.java) when PythonInterpreter ctr is called without
>first issueing a
>Py.initialize, PyJavaClass.lookup is called before Options.setFromRegistry.

Yeah, the initialization is a little screwy. It probably didn't improve
when I made PySystemState subclass PyObject. 

>Should we state that Py.initialize should be issued before using any other
>part of runtime. 

I think that is acceptable if we enforce it in the code. If the
PySystemState.initialize() call is moved to the top the
PythonInterpreter(d, s) method we satisfy the requirement for the usual
cases. The remaining situations are where the developer is creating a
PySystemState by hand before calling the PythonInterpreter ctor. That
must be rare.

The Py.initPython() call in PyJavaClass.lookup() should then be changed
to the functional equivalent of an assert:

 if (!PySystemState.initialized)
    throw new IllegalStateException("PySystemState.initialized() "+ 
                  "not called")


regards,
finn