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/)