Re: [Jython-dev] *loading

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

Hi.

[Finn]
>
> [Samuele]
> >I clarified to myself that jythonc should build the list, use the new
> >order dealing with imports but it is not necessary that it find out
> >that a py pkg is also a java pkg :). The modified runtime support
> >can deal with this.
>
> [Finn]
> >I can make this change. Py.initProxy will then get a new "String[]
> >modules" argument. I'll make it a patch,, i.e I will not commit this
> >until we have settled the complete semantic change.
>
> [Samuele]
> >> During the next weekend I will somehow start experimenting with
> >> merging PyJava*Packages and sys.path java load support.
> >> So we will have some experience about this.
> >
> >Given the flat sematic for sys.path java loading (no dynamic __path__'s)
> >there is nothing to experiment with, fixing things to the new semantic
> >should be simple (and make code cleaner),
> >up to jpythonc building the list (but I think it already gathers that
> >information)
>
> Correct, it does.
>
> >and how radically can we change PackageManager, but I don't
> >think its interface was intended to be public up to the sys.add_package
> >door that will still be there.
>
> I can't quite parse the paragraph above, but I think sys.add_package is
> just about the only intended public interface to the PackageManager.
>
> >It is really just Barry turn to express his opinions and concerns.
>
> Let's not necessarily wait for that. Everybody who have spoken up agrees
> that the new precedence is an improvement. With an implementation
> available we can get some real world feedback from the users that are
> tracking the CVS.
>
> The precedence we are talking about can be described like this:
>
>   Known frozen pys > sys.path (py) > java pkgs > sys.path (java)
>
> I'll get the necessary changes to jythonc ready by saturday.
>

Yes that's the precedence we're talking about.

Let's do that way. If you mean the gathering of frozen packages info, plus
the initProxy,initProps,runMain stuff,
I can work on the rest (the famous
PackageManager,findattrs,PyJava*Package,BytecodeLoader) during the weekend
and for next week.

I imagine I can also fix the two last bugs: very likely the first as part of
the findattr rewriting.

I will disable the unfinished support for poor freezing, we once reffered
to.
And the loading of python modules from mixed java/python pkgs, because with
the new precedence this is no more necessary and just confusing, there will
be only python pkgs that eventually shadow java pkgs but leaving access to
them, or
not shadowed pure java pkgs.

I would like to have poor freezing + loading from classpath/jars of python
pkgs in interpreted mode,
but we can think about it later. For the moment I hope there is nobody
around who really relies on
undocumented/unfinished stuff. The documented part of the story, -jar option
and __run__.py will still
be supported.

[Finn]
>>(a little note) Differently from jython, jythonc follows
>>the proposed precedence py > java. For the rest (java loading)
>>it uses the org.python.core runtime. Is that true?
>
>I don't think so. jythonc creates a list of known java packages and
>passes this list on to sys.add_package() during initialization. This
>creates PyJavaPackages which is currently searched before the python
>modules. I think. But hey, you're the expert <wink>.

I just hope I'm the expert ;). Sorry for the confusion. I was referring to
the jythonc handling of import stmt
at compilation time, not to the interaction between compiled code and jython
runtime. About that
your picture is exact.

regards, Samuele