David Ascher <DavidA@ActiveState.com> writes: > A (probably OT) thought: it feels like this should be viewed in the > context of an even more ambitious (ha!) effort like Tcl's VFS > (virtual file system) -- see http://mini.net/tcl/vfs. That is a > more ambitious approach, but one that I like a lot at least in > theory =). I agree - this is definitely where my thoughts are heading. I originally started from the idea of Java's JAR file support - packed archives of code, which were also executable. Java also supports getting resources out of JAR files. I later found Tcl's VFS, and Starkits. These are, in effect, the same concept. It's worth remembering,though, that all of these things can be done now, with varying degrees of success, in Python by user-level code. All core support adds, really, is a solution to the bootstrapping problem (you can't import zipfile support from a zip file, so it can't be included in an application packaged as a zip file). Another feature I'd find useful is a token (like Perl's __END__) which tells the parser to stop parsing at that point. It allows data to be embedded at the end of a main script. As zipfiles can have arbitrary data added at the beginning, you can then zip up resources and access them via zipfile.ZipFile(sys.argv[0]), or even sys.path.append(sys.argv[0]), allowing you to package code and data together. [Actually, this last approach won't work under PEP 273, as it mandates a file extension of .zip rather than checking the file signature. Rats.] But anything like this is way OT for zipfile imports. It almost certainly needs a PEP if it is to be done right, as simply stealing another language's feature without thinking it through is not going to work... 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