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

[Gordon McMillan]

> Gordon McMillan wrote:

> > [no *.py files]
> > > You also can't import source files *.py from a zip archive.
> > 
> > Apparently some Linuxes / RPM distributions don't deliver
> > .pyc's or .pyo's. Since they're installed as root and run as
> > some-poor-user, I'm afraid there are quite a few installations
> > running off .py's all the time. So while it's definitely sub-
> > optimal, I'm not sure it should be outlawed.
> 
> For Linux/RPM's I think shipping a library directory is better
> than a zip archive.  It is easier to hack on a directory.  I
> think of zip archives as a way to distribute packages, and as a
> replacement for freeze.

There's no reason to believe that telling a Linux distribution 
maintainer that they "shouldn't" do it that way will be 
successful. Heck, he might be a Perl monkey on KP <wink>.
 
> OTOH, maybe we should allow *.py to satisfy imports even if
> it is slow and invisible.
> 
> > [Efficiency]
> > > The key is the archive name from sys.path joined with the
> > > file name (including any subdirectories) within the archive.
> > 
> > DIfferent spellings of the same path are possible in a
> > filesystem, but not in a dictionary. A bit of "harmless"
> > tweaking of sys.path could render an archive unreachable.
> 
> True, but I have little sympathy for case-insensitive file
> systems.  Tweaking of sys.path will have to be done with care. It
> helps that the '/' character is always used in zip, and both
> backslash and colon ":" are illegal in zip archive names.

You don't need case-insensitive for this to come up. Relative 
paths vs. absolute paths; or paths that need norm-ing.

And then you've got the mac which uses a different path 
syntax, and even slightly different path semantics.


- Gordon