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.
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.
| 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.
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.
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.
| 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. JimA