Jack Jansen wrote: > > loader = imp.find_module2(fullname, path) > > if loader is not None: > > loader.load_module(fullname) > > If we want to use this for freeze-like functionality then the loader > will also need a method (or methods) that at the very least return > (for modules for which it makes sense) either the source code for the > module or a file-like object that can be used to read the source code. Features schmeatures! I would agree, but Paul and I have decided to keep the importer protocol real simple, at least for now. Extensions to the importer protocol are definitely needed, but we'd like to concentrate on the basics first. We (as in: all of us) simply need more time to come up with a decent, coherent and simple set of (optional) extensions to the protocol. The zipimporter object now has a get_data(filename) method with which you can do what you want (in a less convenient way), and Paul questions even that addition, as we might not be able to go back once it's in the core. It could even be the subject of a PEP of its own ;-) Also: *anything* that makes zipimporter closer to a file system is going at it from the wrong direction. We *first* need a virtual file system, then an import hook that can import from it, and *then* a zip back end... Just
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