Correct MAX_N in Lib/zipfile ZipExtFile#144973
Open
jberg5 wants to merge 1 commit intopython:mainfrom
Open
Conversation
serhiy-storchaka
approved these changes
Feb 19, 2026
Member
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
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.