[Python-Dev] PEP 273: Import Modules from Zip Archives

Gordon McMillan gmcm@hypernet.com
Wed, 31 Oct 2001 17:31:02 -0500


Jeremy: 
>     >> Requirement: A ZIP archive be usable any version of Python
>     that >> supports ZIP-based imports.
> 
>     Gordon> Hmm. You want .pyc's with every known magic number
>     (there goes Gordon> disk space)? Or just source and throw
>     away the .pyc?  Or maybe Gordon> insert into the zip file?
>     Either way, there goes speed.
Skip:
> Can't zip files be treated conceptually as directories?  If I
> import a py-based module from a zip archive I see no particular
> reason the byte-compiled file can't be added to the archive
> (conceptually, written to the directory), speeding up the import
> the next time.  Is this not possible?

Zip files are normally unpacked to the filesystem and rebuilt 
when modified. If this feature is desired, I think MetaKit would 
be a much better file format (I have used MetaKit as a pyc 
archive so I could replace individual modules).

But unless you want to big-boy SQL servers as "archives", 
you're going to have trouble with multi-user.

To combine this with Jeremy's requirement, we can't put the 
.pyc's alongside the py's anyway, we need some 
(disappearing) node in the hierarchy to hold the byte code 
version (magic number). A bit more trickery for import.c.

We can meet a real need as long as we don't put tail fins and 
heavy chrome all over a Yugo (zip files). They're easy to 
produce & ship. I don't think we should disallow .py files, but I 
think 99% of their use will be version specific .pyc's only (and 
many of those to users who think "traceback, innermost last" 
is Aramaic). It's nothing compared to the effort of dealing with 
the binaries across versions (or even the std lib across 
versions, sometimes).

OTOH, I'm worried that  the extension-modules-inside-
packages requirement is going to break import.c's back. There 
are many undocumented features of the implementation of 
import that are relied on (such as xml.__init__'s trick, or 
extentions modules inside packages). 

Heck, we might even have to clarify the rules.

doom-and-gloom-and-goblins-ly y'rs

- Gordon