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