[Python-Dev] zipimport & import hooks (original) (raw)

Finn Bock bckfnn@worldonline.dk
Fri, 06 Dec 2002 15:22:07 +0100

• Previous message: [Python-Dev] VFS (Was: zipimport & import hooks)
• Next message: [Python-Dev] Another approach for the import mechanism
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[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 . 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

• Previous message: [Python-Dev] VFS (Was: zipimport & import hooks)
• Next message: [Python-Dev] Another approach for the import mechanism
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]