On 8/13/07, David Huebel <davidhuebel@...> wrote:
> On 8/13/07, Frank Wierzbicki <fwierzbicki@...> wrote:
> > So I don't remember how we finished that discussion. I remember that
> > in general Java merges parallel packages, and Python has a first
> > package loaded wins strategy -- which would we do here for Python
> > source? I'm guessing we would follow the Java convention and merge
> > packages on the classpath, since having things on the classpath
> > implies a Java bias -- and then we would continue to use the Python
> > strategy on python.path -- but would that really work?
> I agree that packages on the classpath should be merged. All files on
> the classpath are conceptually in the same top-level directory --
> there's no way to distinguish between parallel directories without
> getting each resource's URL and parsing it, which can't be reliably
> done. This can be unified with the current Python semantics by
> treating the class loader as if it were a single directory in
This is exactly where I ended up in the previous discussion, so I concur!
> (Actually, I think it might be good to exclude the classpath by
> default and allow entries of the form '__classpath__' or
> '__classpath__/python/lib' in python.path.)
We have a __classpath__ entry now, and it's in there by default. It's
what JavaImporter keys off of and that enables the importation of Java
classes and packages, so I think it should stay in by default.
However, JavaImporter is just a path hook(per PEP 302), so it has no
special access to Jython's internals. It should be equally easy to
write a new path hook as to bolt this on to JavaImporter. This would
have several advantages: it could key off a different sys.path entry
so it wouldn't be on by default, you could start using it now without
a new release of Jython(I don't know how critically you need this) and
you could specify prefixed entries in jars like you were suggesting
with '__classpath__/python/lib'(except with a different special string
since __classpath__ is already taken).