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

[Guido van Rossum]

> Guido van Rossum wrote:
> 
> > Hm, I wonder if we couldn't just link with the libz.a C library and
> > use the C interface, if you're implementing this in C anyway.
> 
> Since zlib is often in a DLL or shared library (.so), I am afraid of
> portability problems if we use the C interface.  For example, on Windows,
> linking python.dll with zlib.dll would cause python.dll to fail if zlib.dll
> were unavailable, even if zlib.dll were never accessed.  It also happens
> that use of the zlib module is easier.

OK, good enough.  (I'm getting more and more curious about your
implementation. ;-)

> > I wonder if we need to make an additional rule that allows a .pyc file
> > to satisfy a module request even if we're in optimized mode (where
> > normally only .pyo files are searched).  Otherwise, if someone ships a
> > zipfile with only .pyc files, their modules can't be imported at all
> > when python -O is used.
> 
> Yes, I agree.  How about if we look for the correct .py[co] first,
> and if that fails, look for the other?  Either will satisfy the
> import, right?  If .pyc is wanted, .pyo is OK too.

Sounds good to me -- this might be a good rule anyhoo.

> > |     The only way to find files in a zip archive is linear search.
> > 
> > But there's an index record at the end that provides quick access.
> 
> It is this index which is searched linearly.

That can't possibly take any time compared to other stuff -- it's a
relatively short in-memory table.

> > Do we get an "module not found" error or something better, like
> > "compressed module found as <filename> but zlib unavailable"?
> 
> We get "module not found".  The second is awkward, because the
> module may be found later in sys.path.

Hm.  Does it at least spit out a warning when zlib is needed but not
available?  It can be awkward to debug the situation where you get a
module from the filesystem rather than the version from the zipfile,
even though it is in the zipfile.  While the compression method is
listed in the zip info, it's not the first thing someone would look
for unless they were aware that this failure mode existed.

Since obviously the intention of putting the module in the zipfile was
that it should be found, I think that failure to decompress should be
turned into an immediate error -- the same way as a syntax error gets
reported and not turned into a "skip to the next directory in
sys.path" effect.

> > Well, this is the domain of getpath.c, and that's got a different
> > implementation for Unix and Windows anyway (Windows has PC/getpathp.c).
> 
> I would like discussion on what the additional sys.path names are.

Well, propose some.

> > |     A C implementation exists which works, but which can be made better.
> 
> I can upload it for inspection, but I don't want it to be a patch
> because it is not done yet.

Just say so in the patch.  You can upoad anything you want. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)