[Python-Dev] VFS (Was: zipimport & import hooks)

Paul Moore lists@morpheus.demon.co.uk
Sat, 07 Dec 2002 15:43:52 +0000


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