Greg Stein wrote: > > Gordon McMillan wrote: > >... > > def _reload_hook(self, module): > > # gmcm - Hmmm, reloading of a module may or may not > > be impossible, > > # (depending on the importer), but at least we can > > # look to see if it's ours to reload: > > if hasattr(module, '__importer__'): > > if getattr(module, '__importer__') == self: > > raise SystemError, "reload not yet implemented" > > return self.__chain_reload(module) > > I've folded this in (finally). > > New imputil.py to be published in a bit... As a result of all this import discussion I am a bit worried that the python library *.pyl file format may not be powerful enough. I have always thought in terms of unique top-level names and a format which supports import of modules and packages. But this does not support the full functionality of PYTHONPATH. For example, PYTHONPATH can (and is) used to select the correct plat-* directory files. And the format may not support Jim Fulton's fancy local import scheme. And what if someone invents a third thing to import besides a module or a package? PYTHONPATH is not going away nor should it. How about if the *.pyl file format is exactly a directory structure? I mean that the table of contents is limited to paths starting with a directory name only, and that the seperator is '/' instead of '.'. So a listing would be identical to the output of 'ls -R'. So: Lib/string.pyc Lib/exceptions.pyc Lib/plat-sunos4/... mx/__init__.pyc mx/... package2/... dir3/... ... The implied PYTHONPATH for this file is ["Lib", "."]. Since the format is exactly a directory tree, it is guaranteed that whatever PYTHONPATH or imports can do now or in the future with a directory tree, it can still do it with a *.pyl file. Jim Ahlstrom
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