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