> PEP 273 does not mandate a particular file extension for zip > files. However, both current implementations (Jim Ahlstrom's patch and > Just's import hooks) recognise zip files via the extension ".zip". > > I'd like to suggest that this should not be the case, and that > zipfiles should be recognised by the embedded signature, as is done by > zipfile.is_zipfile(). This will (slightly) slow down the initial > checking for zipfiles, as it requires a file read, but if the result > of the check is cached the performance impact will be minimal. > > The main advantage of this is in generality. However, I have a > specific usage in mind - namely, concatenating a Python script with > its supporting code as a zip archive. (Zip archives can have arbitrary > data prepended without affecting their validity). Then, simply by > executing > > sys.path.append(sys.argv[0]) > > the script can access its own embedded modules. > > One problem with getting this to work is that at present, the Python > parser will choke on data appended to the script. This can be avoided > under Windows by a system-specific hack, of embedding a ^Z character > in the script (which text-mode I/O treats as EOF) just before the > appended data. In the longer term, a language-mandated "stop parsing > here" token, like Perl's __END__, might be useful. But that's not > something I'm proposing right now (unless an expert in Python's parser > steps up and says "oh, that's easy - I can implement that in a couple > of lines of code" :-)) > > Any comments? -1. Too much of a hack. --Guido van Rossum (home page: http://www.python.org/~guido/)
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