Various core and test changes

[tybug]

Split from #3818. I could split this further if desired, with all the draw_bits changes in a single PR.

Changes:

• move cu.choice to ConjectureData
• improve minimal readability with nonlocal
• migrate away from draw_bits in various test files in preparation for its removal. Or at least, taking a back seat relative to the ir.

There were some test changes where the extra boolean draw from > 24 bit integers caused the test to fail.

hypothesis/hypothesis-python/src/hypothesis/internal/conjecture/data.py

Lines 1260 to 1262 in 980042e

	if bits > 24 and self.draw_boolean(
	7 / 8, forced=None if forced is None else False
	):

I mostly remedied this by reducing the bit size down to 20 for these tests. It does make me wonder if we're doing the appropriate thing by biasing the distribution in this way at the ir level, rather than at the strategy level (integers()).

[tybug]

Looks like test_can_learn_to_normalize_the_unnormalized became flaky due to this (e.g.). Will look into it.

[Zac-HD]

I mostly remedied this by reducing the bit size down to 20 for these tests. It does make me wonder if we're doing the appropriate thing by biasing the distribution in this way at the ir level, rather than at the strategy level (integers()).

Hmm, good question! IIRC we used 2**24 as a special value because it ensured that unicode characters were chosen without (additional) bias. I'd probably leave it alone for now, but we should do an audit of this kind of heuristic once we're using the IR everywhere - there are probably a bunch we'll be able to clean up then.

---

General thoughts on this PR: looks good to me. Two approaches you can take to this kind of pulled-out stage are to (1) defer anything that we can't merge ~immediately to a future PR, or (2) keep working on it here until it passes to make future PRs easier. I generally favor a bit of (2) followed by (1) if I'm feeling stuck or just slowed down; it's basically the same question as pulling out part in the first place 😁

[tybug]

that approach makes sense 👍.

In this case I didn't get stuck for too long on test_can_learn_to_normalize_the_unnormalized. It was a rare case where a test is failing because we did too good of a job 😄. dfa.normalize only adds a new normalization if the shrinking differs within 100 calls. With draw_bits, the shrinking differed within that time frame. After using the IR, the shrinking was usually consistent (hence the flakiness). Which means we were doing a better job shrinking to a normalized example with the IR than without!

The solution? Make the property even harder to shrink to a normalized value.

[Zac-HD]

🎉

[Zac-HD]

I'm trusting you to track this; I'd probably link to this code from a comment on the IR issue after merging.

[tybug]

left a task in the pr description 👍 (less likely for me to lose it than a comment, and github doesn't easily let me leave reviews on unrelated files.)