From: "Samuele Pedroni" <pedronis@bluewin.ch> > > zipimporter.c > > - removed the subdir feature, which allowed the path to the > > zip archive to be extended with a subdirectory. PEP 273 > > stated this was needed for package support (and only for > > that). However, with the new import hooks this is no longer > > true: a path item containing the plain zip archive path can > > also deal with submodules (find_module receives the full > > module name after all). Therefore a pkg.__path__ from a > > package loaded from a zip archive will contain the *plain* > > zip archive path. > > - as a consequence I could simplify and clean up lots of > > things (esp. zipimporter_init: eg. it no longer needs to > > check sys.path_importer_cache; yay). Getting rid of the > > zipimporter.prefix attribute altogether helped a lot in > > other places. > > - this change additionally enabled me to get rid of the > > restriction that zip paths must end in .ZIP or .zip; any > > extension (or even no extension) will now work. > > will not this break __path__ manipulations? > further this change is backward incompatible with what is allowed by Jython 2.1, it was considered a feature to be able to put path/to/a.zip/python in sys.path, so that the a.b package would be looked up under path/to/a.zip/python/a/b. regards.
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