Correct MAX_N in Lib/zipfile ZipExtFile#144973
Merged
serhiy-storchaka merged 2 commits intopython:mainfrom Feb 19, 2026
Merged
Conversation
serhiy-storchaka
approved these changes
Feb 19, 2026
Member
serhiy-storchaka
left a comment
serhiy-storchaka
left a comment
There was a problem hiding this comment.
LGTM. 👍 Good catch! 🐟
Could you please also fix other cases in tests (even in comments)?
Lib/test/test_compile.py: g = +9223372036854775807 # 1 << 63 - 1
Lib/test/test_compile.py: h = -9223372036854775807 # 1 << 63 - 1
Lib/test/test_unpack_ex.py: >>> s = ", ".join("a%d" % i for i in range(1<<8)) + ", *rest = range(1<<8 + 1)"
Lib/test/test_unpack_ex.py: >>> s = ", ".join("a%d" % i for i in range(1<<8 + 1)) + ", *rest = range(1<<8 + 2)"
Lib/zipfile/__init__.py: MAX_N = 1 << 31 - 1
serhiy-storchaka
added
skip news
needs backport to 3.13
Contributor
Author
|
Thanks @serhiy-storchaka ! Have addressed the others that you mentioned. |
|
Thanks @jberg5 for the PR, and @serhiy-storchaka for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this pull request
Feb 19, 2026
"<<" has lower precedence than "-". (cherry picked from commit 4141f0a) Co-authored-by: J Berg <j.berg2349@gmail.com>
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this pull request
Feb 19, 2026
"<<" has lower precedence than "-". (cherry picked from commit 4141f0a) Co-authored-by: J Berg <j.berg2349@gmail.com>
|
GH-145022 is a backport of this pull request to the 3.14 branch. |
|
GH-145023 is a backport of this pull request to the 3.13 branch. |
serhiy-storchaka
pushed a commit
that referenced
this pull request
Feb 19, 2026
serhiy-storchaka
pushed a commit
that referenced
this pull request
Feb 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is so small that I didn't think it was worth making an issue, but let me know if you disagree!
Basically it looks like we've had this (extremely minor) operator precedence bug since 2010. I am 99% sure the original implementation intended to set MAX_N to be (2^31)-1, but ended up with (2^30), since
It's hard to imagine a scenario where this would have made a difference. Maybe a highly compressed file that expands to 2gb previously was taking two iterations to process when it could have been done in one? But at that point I imagine you wouldn't really notice the additional overhead.
That said, it feels like fixing this is the right thing to do.
AI use disclaimer: I had claude (with Opus 4.6) act as a sort of code reviewer and scan the standard library for issues, and it immediately spotted this one.