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