Re: [Jython-dev] moduleDictInit is not called

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

Hi.

[Finn]
> 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.
For that we have classInitDict, which invocation seems to me in the right
place.
Clearly classDictInit is ok for manipulating the __dict__ but should not run
a module main.
Why the InitModule and his support code are still left around?
Should we clean that?

> >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.
I think we should put such code that deal with $_PyInner classes
in loadBuiltin and loadFromPath. ((The builtins coming from compilation
 exceptions and cPickle_exc ... should then be better recompiled)).
But then I imagine that a user would expect to be able to put
a jar containing compiled modules in classpath and be able
to import them. The simplest straightforward impl
will not offer that, limiting the search of $_PyInner classes
to sys.path as for .py and $py.class files.
I do not know if can offer the latter with a clean semantics,
but we can use for that openResourceAsStream.
I'm also asking myself if we should consider the dynamic value
of __path__ when looking for $_PyInner modules or not.
(( Maybe all that is related to the big design question, wheter we want
to load .py($py.class) also from classpath and have jars
on sys.path... ))
Notice that with this design choice if someone load a compiled
module through a java package it will get simply the java class
not the module, for me this makes sense but then we remain
with the problem of how to enable the usage of compiled py classes
as java classes from jython. You have always declared that this
is really difficult and I should admit that I have not studied it yet,
can you list what are the serious problem with that?

> 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.
Sorry, I do not understand what  you mean with that.

regards, Samuele