bpo-25711: zipimport rewritten in Python #4023
Conversation
| @@ -0,0 +1 @@ | |||
| zipimport has been rewritten in pure Python. | |||
There was a problem hiding this comment.
A separate news entry for the DeprecationWarning -> TypeError change for creating zip importers directly from bytes paths would probably make sense. (Or at least mentioning it in this one)
|
|
||
| _importing_zlib = False | ||
|
|
||
| # Return the zlib.decompress function object, or NULL if zlib couldn't |
There was a problem hiding this comment.
NULL doesn't exist in python. Should be "raises a ZipImportError ..."
|
I wonder if it's really so useful to keep this PR around, especially in light of @Yhg1s promised rewrite? |
|
It can always be re-opened. I do still plan to open-source my zipimport rewrite, hopefully before PyCon, but it is in C, not Python. If people value having a pure-Python version of zipimport in the standard library, that's a different matter. (I do recommend not using zipimport.c as a guide for a pure-Python version of zipimport, as this version has done... It has a number of bugs, like how it handles offsets in the central directory and how it closes and then re-opens the ZIP file, which may have changed, without re-reading the central directory. Also, no zip64 support. And as written, zipimport.py (partially) reimplements zipfile, which is a bit of a shame... Although I also have plenty of issues with zipfile :-P) |
|
Alright, I'm closing this since I don't think it has a viable future. It was mainly an exercise in trying to convert the original bpo patch into a branch+PR. |
This starts from @serhiy-storchaka 's zipimport-2.patch from bpo-25711. It does not yet work, but it will be easier to comment on and fix as a PR rather than a patch.
https://bugs.python.org/issue25711