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?
Paul.
--
This signature intentionally left blank
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