Re: [Jython-dev] moduleDictInit is not called

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

On Sat, 18 Nov 2000 06:20:22 +0100, you wrote:

>First I should apologize if my patch is a little bit confusing.

Not at all. I had not thoroughly checked the execution path of the new
code.

>I tried the last commited version of the patch that should allow to load =
>compiled python modules
>and get them as working modules in the interp (based on invocation of =
>moduleDictInit).
>
>Given my patch, the point where  moduleInitDict is called is somehow =
>wrong.
>The point is that I have left createFromClass(String,InputStream) in the =
>code
>but this is no longer called and so createFromClass(String,Class) for =
>classes
>coming from sys.path.
>This make indeed sense: java classes are treated more symmetrically =
>indipendently from where they come
>as we wanted but so moduleInitDict is not called when supposed. Clearly =
>here we want to able
>to break the symmetry when this make sense and we are loading a compiled =
>module.

My *intention* for moduleInitDict was as a general hook which any java
class could implement if it wanted some control over its __dict__ when
it is imported. It was not only for compiled modules.

>The problem is that given the patch there is no clear, coherent point =
>where to put=20
>moduleDictInit invocation.

Right. It is a problem for the lazy loaded classes.

>My (not deeply tested) suggestion to get the desired functionality is =
>not to use=20
>moduleDictInit but simply to repeat the behaviour used when executing =
>compiled
>code outside of the interp:
>the interp when looking for x should try not only x.py and x$py.class =
>but
>also x$_PyInner.class and then in this last case create an instance , =
>getMain and execute
>the obtained code in the dict of a new module.

That will allow initialization of the module dict when importing the
module and at the same time avoid the initialization when the proxy is
used from python. In addition type(x) would be ModuleType instead of
TypeType.

So all together, your suggestion sounds better.

Still, I feel a link is missing. Some way to go from x.class to
x$_PyInner.class, maybe as some public API in imp.java or Py.java.

regards,
finn