Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Minor test fixes for zlib and gzip#22408

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
rhpvorderman wants to merge3 commits intopython:main
base:main
Choose a base branch
Loading
fromrhpvorderman:smallzlibtestfixes

Conversation

rhpvorderman
Copy link
Contributor

@rhpvordermanrhpvorderman commentedSep 25, 2020
edited
Loading

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.

  1. a decompressor is finished when it reaches eof. Not when it has no unconsumed tail left. The last case merely meaning it was able to consume all input, and not meaning it is finished.
  2. A gzip header only stores the basename of the file. The expected name in the test used the full path. Presumably because it was a relative path with no subdirectories.

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 thedocs. It autodetects gzip or zlib style compression. That is quite a neat feature!

The unconsumed tail has a possibility to be empty, even if the end of compression is not reached
@taleinat
Copy link
Contributor

taleinat commentedSep 26, 2020
edited
Loading

@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 onthe 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.

@rhpvorderman
Copy link
ContributorAuthor

@taleinat, No reviews so far. Not that these issues are very pressing.

@taleinat
Copy link
Contributor

Ping,@Yhg1s?

@erlend-aasland
Copy link
Contributor

According to thedevguide, this does not qualify forskip issue. IMO, this warrants an issue, despite being fairly trivial.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@Yhg1sYhg1sAwaiting requested review from Yhg1s

Assignees
No one assigned
Labels
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

7 participants
@rhpvorderman@taleinat@erlend-aasland@the-knights-who-say-ni@ezio-melotti@bedevere-bot@AA-Turner

[8]ページ先頭

©2009-2025 Movatter.jp