Repository navigation
Conversation
pganssle
commented
Oct 19, 2026
…thesis stubs The stubs in test.support._hypothesis_stubs only cover the strategies and decorators the existing property tests happen to use, so a test that wants hypothesis.stateful, or the timezones() and ip_addresses() strategies, fails to import when Hypothesis is not installed. This adds those names. The stateful API has no equivalent of @example, so there is nothing for the stub to replay: a state machine's TestCase is skipped and run_state_machine_as_test raises SkipTest. The decorators are accepted so that state machine classes can be defined at import time. Real Hypothesis only exposes hypothesis.stateful once the submodule has been imported, so hypothesis_helper now imports it, making the attribute available in both modes.
pganssle
force-pushed
the
email-fold-hypothesis
branch
from
October 19, 2026 21:30
ad9482f to
aeb677f
Compare
…he line When an encoded word does not fit in the remaining space of a line, _fold_as_ew shrinks the chunk being encoded one character at a time until it fits. Nothing stops it from shrinking the chunk to nothing, and an empty chunk makes no progress: the loop appends an empty encoded word and a new continuation line forever. This is reachable whenever a single character's encoded form is wider than a fresh continuation line, e.g. any character outside the BMP with max_line_length=20 (the q-encoded word is 24 characters). The two earlier fixes in this area (bpo-33529, bpo-36564) handled lines too short for the RFC 2047 chrome, but not lines too short for the chrome plus one character. This keeps at least one character in the chunk, so the loop always advances and the line runs over max_line_length instead. That matches what _refold_parse_tree already does when it cannot fold a part at all, and avoids raising for widths that work for every other input. The regression test pins the exact output, as the earlier two did. The Hypothesis property checks that folding any unstructured value at any width either raises HeaderParseError (only possible at widths of 13 or fewer, where no encoded word fits) or reparses to the same value modulo leading whitespace, which the parser drops.
…oded words A header value that happens to be a well-formed RFC 2047 encoded word is written out verbatim, so reparsing the message decodes it: folding 'Subject' '=?utf-8?q?x?=' comes back as 'x'. As far as I can tell RFC 2047 section 5 requires an encoder to encode such text. This records the behavior as an expected failure rather than keeping the round trip property away from it, so the test starts failing when the generator is fixed.
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
1 participant
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.
Stacked on #159770; only the top two commits are new here.
When an encoded word does not fit in the remaining space of a line,
_fold_as_ewshrinks the chunk being encoded one character at a time until it fits. Nothing stops it from shrinking the chunk to nothing, and an empty chunk makes no progress: the loop appends an empty encoded word and a new continuation line forever.This is reachable whenever a single character's encoded form is wider than a fresh continuation line, e.g. any character outside the BMP at
max_line_length=20(the q-encoded word is 24 characters). The two earlier fixes in this area (bpo-33529, bpo-36564) handled lines too short for the RFC 2047 chrome, but not lines too short for the chrome plus one character.The fix keeps at least one character in the chunk, so the loop always advances and the line runs over
max_line_lengthinstead. That matches what_refold_parse_treealready does when it cannot fold a part at all, and avoids raising for widths that work for every other input.Tests, next to the two earlier infinite-loop regressions in
test_policy.py:None) either raisesHeaderParseError(only possible at widths of 13 or fewer, where no encoded word fits) or reparses to the same value modulo leading whitespace, which the parser drops. 100 examples take about 0.2 s; the explicit examples replay under the stubs.expectedFailuretest for a second finding: a header value that is itself a well-formed encoded word is written verbatim, so reparsing decodes=?utf-8?q?x?=tox. As far as I can tell RFC 2047 §5 requires such text to be encoded. Recorded rather than worked around, so it starts failing when fixed; a separate issue for it is coming.