[Python-Dev] zipimport & import hooks

[Finn Bock]

[Just van Rossum]

> This gets nessesarily more complex for packages, as now we also have to cater
> for __path__ items of this form: "/path/to/my/archive.zip/packagedir". In this
> case we need to create a "subimporter" of "/path/to/my/archive.zip" if only
> because we don't want to reread the zip archive's file index. 

and

 > The last patch I posted here inserts zipimporter instances in
 > __path__, just as it replaces *.zip sys.path entries with zipimporter
 > instances. Allowing objects on sys.path/pkg.__path__ is still the most
 > lo-tech solution, but it seems there's too much opposition for that,
 > so I'll continue to work on an iu.py-inspired solution.

You are getting mighty close to what Jython has hardcoded for its .zip 
support <wink>. If the framework you come up with should be usefull from 
jython, then it is very important that it also somehow support cleanup. 
If objects are added to sys.path and __path__ then cleanup is easily 
handled in the __del__ method of the object. If the object is placed on 
some kind of shadowpath then some other cleanup means should be available.

 From jython I can also note that:

- The automatic conversion of a '*.zip' string to a SyspathArchive (aka
   zipimporter) object works, but it works by magic and I'm not happy
   with this kind of identity change. It was just the best I could come
   up with that allowed easy cleanup as well as only-strings-on-sys.path.

- Not all jython's potential importers can be represented by a string.
   Obviously such an importer can't be added on our PYTHONPATH, but must
   be added by program itself. An importer that is based around a java
   classloader is an obvious example of such an importer.

So I would prefer that:

- non-string objects was acceptable values on sys.path. If
   string-subclasses becomes a requirement, that is also fine.

- if strings on sys.path are changed to something else, it should be
   done explicit and not implicit at the time of the first import that
   uses the sys.path entry.


It would also be nice if user code could use the import framework to 
access resources, data files, gifs etc. That would match java's 
ClassLoader.getResourceAsStream() method.


regards,
finn