[Python-Dev] PEP 273: Import Modules from Zip Archives (original) (raw)
Gordon McMillan gmcm@hypernet.com
Mon, 29 Oct 2001 10:41:04 -0500
- Previous message: [Python-Dev] PEP 273: Import Modules from Zip Archives
- Next message: [Python-Dev] PEP 273: Import Modules from Zip Archives
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Gordon]
> After extensive use of imputil (which puts objects on > sys.path), I think we might as well make it official that > sys.path is a list of strings. [Guido] Interesting. So you think imputil is wrong to put objects there? Why? (Not arguing, just interested in your experience.)
Too much code (some left in the std lib) says: for d in sys.path: os.path.join(d, ...) and that's the line that barfs. It doesn't barf if d is a string.
[Gordon]
> DIfferent spellings of the same path are possible in a > filesystem, but not in a dictionary. A bit of "harmless" > tweaking of sys.path could render an archive unreachable.
Hm, wouldn't the archive just be opened a second time? Or do I misundestand you?
Without seeing the C code, I don't know if it will open it a 2nd time. I keep an open file for each archive, but I'm careful that however it's spelled, I only open the archive once. Jim is apparently closing the file, so opening a 2nd is probably not as painful. OTOH an open / seek for each satisfied import is relatively expensive (though still cheaper than a fs import).
> [zlib must be available at start] > I'll agree, and agree with Guido that the coolest thing would > be to make zlib standard.
But we'd have to make sure it's statically linked. (Fortunately, we already link it statically on Windows.)
So to avoid statically linking it twice, I assume zlib would be a mandatory builtin.
[Gordon]
> Personally, I think package support stretched import.c to it's > monolithic limits and it's high time the code was refactored to > make it sanely extensible.
Yes -- this has been on my TODO list for ages. But who's gonna DO it?
I published iu4 which I think comes very close to the "right" model. If it's close enough, I'll download 2.2 and see if I can make those into new style object subclasses[1].
- Gordon
[1] As an app developer, I usually have to look backwards, not forwards. I've got 6 machines, each with at least 2 Pythons, so I no longer deal with betas :-(. Even when they have cool things like generators and subclassable C types.
- Previous message: [Python-Dev] PEP 273: Import Modules from Zip Archives
- Next message: [Python-Dev] PEP 273: Import Modules from Zip Archives
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]