| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
The unconsumed tail has a possibility to be empty, even if the end of compression is not reached
|
@rhpvorderman, thanks for this PR! The reasoning and changes suggested look good to me, but I'm not an expert on this. I've asked @Yhg1s, listed on the experts index as the expert on zlib, to review this. You're welcome to ping me in a few weeks if nobody else has reviewed this PR. |
Sorry, something went wrong.
|
@taleinat, No reviews so far. Not that these issues are very pressing. |
Sorry, something went wrong.
|
According to the devguide, this does not qualify for skip issue. IMO, this warrants an issue, despite being fairly trivial. |
Sorry, something went wrong.
|
No response since 2020. Marking as pending close. |
Sorry, something went wrong.
|
I will close it myself then. It is not of paramount importance as it is technically not broken. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This is very minor so I did not create an issue on bugs.python.org.
I am working on a gzip-compatible library and used the tests from cpython to ensure that it was indeed compatible. I found these minor oversights when testing the library.
I also found test cases testing a Wbits of 32+15. Wbits sizes over 31 are undocumented in both the python and zlib documentation. Can anyone explain to me what these test cases are for, and why it is a hard requirement that these undocumented assumptions may never be broken by future python releases? I found it in the docs. It autodetects gzip or zlib style compression. That is quite a neat feature!