Guido, I call for a Pronouncement: I'm seeing some convergence on basic criteria needed for a Grand Import Redesign, but I'm not seeing convergence on the actual design itself. Time is running short for 2.3, and people making hasty decisions make poor decisions. OTOH, the complaints raised about the current patch for PEP 273 have merit, I think. On the gripping hand, we really want PEP 273 in some form for 2.3. So here's my proposed compromise: Split the PEP 273 patch into two parts. The first part is the absolutely critical modifications to import.c, which basically boils down to making a function call every time you access a '*.zip' string on sys.path. Everything else goes into zipimport.c, a compiled-in module like socket. (I'd even support making zipimport.c an include file for import.c) Yes, this means we lose the caching for non-ZIP files for 2.3 -- I vote YAGNI. Yes, this makes more work over the long haul, but it saves stress and time now. Yes, it's more work than just accepting the current PEP 273 patch, but I think there are too many good arguments against that. zipimport will *NOT* be a publicly exposed library for 2.3, possibly never. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." --reddy@lion.austin.ibm.com
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