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.
In an attempt to help with HypothesisWorks#3074, I have added type annotations to
hypothesis/internal/conjecture/engine.py
. I have checked these type hints with bothmypy
andpyright
, and verified a few of the trickier-to-statically-determine types by checking their runtime types in the tests.There are two instances that I'm still confused about.
Overrun
be a validvalue
forself.interesting_examples
?In all places but this one sample (lines 389 in this PR), all of the keys for
self.interesting_examples
areConjectureResult
. However, this assignment may possible beOverrun
. Indeed, in one test,test_backend_can_shrink_bytes
, this does occur. This seems (to me) to be the only place in the tests where thisOverrun
assignment occurs. IfOverrun
is a validvalue
, then this violates the typing in several other places whereself.interesting_examples
is accessed, but nothing seemed to ever trip up the asserts I had placed in those places (and since removed). IfOverrun
is indeed valid, then I will need to update the hints forself.interesting_examples
, and I'd like to better understand the guarantees that ensureOverrun
is never a value in other places (so the type narrowing asserts are legal). Many, but not all, of those references are inshrink_interesting_examples
for example.trial_data
because of a caughtPreviouslyUnseenBehavior
exceptionIn line 842,
trial_data
is defined inside of a try-except block. In the happy path, this variable is always defined. On the otherhand, unless I am misunderstanding something, if aPreviouslyUnseenBehavior
is thrown, that variable will not be defined, meaningtrial_data.observer.killed
and a few other later instances will reference an uninitialized variable. This never happens in the tests, and I've certainly never experienced it while usinghypothesis
.Am I misunderstanding the flow of the code here? Is this try-except superfluous? Or is there a genuine error in how the exception is handled?
On top of those two confusions I have,
mypy
also complains about some string literals as keys to a TypedDict (line 247), because it does not consider the concatenation of two literals to be a literal. See the code snippet below. Personally, I feel like this is an error inmypy
--pyright
does not have this complaint. If we would likemypy
to be fully happy, I can either add a# type: ignore
, or refactor the code to only use true literals. If we don't care thatmypy
complains, then no change is needed.Doubtless, I've missed or misunderstood some pieces. I am happy to revise and iterate!