Message3905

Thanks for the comments. The primary difference between this and what
you describe is the necessity to use getResourceAsStream() in the applet
context. My patch doesn't actually change the behavior with regard to
__classpath__: that still works as usual (in that it will still be
searched for .class files but not .py files).

What I changed is the behavior of the importer when Jython is being
hosted by an applet. In such a case you want to be able to read .py and
py$class files from your *applet jar* rather than from the filesystem.
This allows you to distribute a complete, self-contained jar file for
the applet to use so that end users don't need anything installed on
their local machines (except, of course, a browser supporting Java applets).

In terms of PEP302, that does sound like a good model to consider.
However, there will have to be at least a minor change to imp.java to
support creating the input stream using getResourceAsStream rather than
using file I/O. Unfortunately, this is one area where applets really are
just different from and incompatible with their application
counterparts. Part of the patch I wrote just involves cutting and
pasting the loadFromSource method; that should ideally be refactored
anyway, to allow the caller to ask for the stream to come from the
applet rather than the file system.

The ultimate goal of all this is to allow Jython users to distribute the
same code as either an applet or application. That means that finding
.py files at run-time has to work in both contexts and -- in the applet
case -- without relying on particular files being on the end user's
local file system.

However, I will look into the PEP302 approach and see if that simplifies
things.