[me]
In the current implementaion in jython, we can put python modules under any path and add the zipfile!path to sys.path:
sys.path.append("/path/to/zipfile.zip!Lib")
which will look for Lib/Q/R/modfoo.py (and Lib/Q/R/modfoo$py.class) in the archive.
[GvR]
Maybe it's possible to allow "/path/to/zipfile.zip/subdirectory/etc/" in sys.path? That sounds better than picking a random new character as delimiter.
Fine by me. From a java POV the bang ("!") was not random:
import java java.lang.Class.getResource(type(1), "/java/lang/Class.class") jar:file:/D:/java/jdk1.4/jre/lib/rt.jar!/java/lang/Class.class
The URL library in java can of course open the string above as an input stream.
Would entries in the static python dict be removed when a zipfile is removed from sys.path?
It can be arranged that they are removed at some later point (e.g. when sys.path is next searched).
An API to do this could be usefull for jython. Right now we depend on the GC thread to close the file. Since files are a limited resource it would be a good thing to have an explicit way to clean up the cached resources. I don't expect the lack of a cleanup method to be a huge problem in real life.
What is the __path__ vrbl set to in a module imported from a zipfile? Can the module make changes to __path__ and will be changes to used when importing submodules?
What value should __file__ have?
IMO these two questions are answered by the pathname semantics that Jim proposes: __file__ = "/C/D/E/Archive.zip/Q/R/modfoo.pyc" and __path__ = ["/C/D/E/Archive.zip/Q/R"].
Ok. I assume that as long as some module exists with a __path__ like this, it not possible to clear the cached entries for /C/D/E/Archive.zip. If importing from zip is regarded mainly as a deployment/bootstrapping feature, then the cleanup issues does not exist. I have no problem looking at it as a deployment feature (that is all I need it for myself), I just didn't dare to put such a limit on my jython implementation. regards, finn