[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4