Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use our own global Random instance instead of random #2135

Closed
DRMacIver opened this issue Oct 15, 2019 · 2 comments · Fixed by #3139
Closed

Use our own global Random instance instead of random #2135

DRMacIver opened this issue Oct 15, 2019 · 2 comments · Fixed by #3139
Labels
enhancement it's not broken, but we want it to be better

Comments

@DRMacIver
Copy link
Member

As per discussion in #2129, currently if users seed the global PRNG before each test they will get bad results because tests will be weirdly correlated with eachother. We have plenty of mechanisms for controlling determinism if they want to use them, they shouldn't be using this one.

It is still important that we respect random.seed at a global level - i.e. that calling it once makes the whole test suite deterministic - but we don't want to respect it at a per test level.

My recommended solution is as follows:

  1. We store a single Random instance in hypothesis.core which we use as our source of random seeds instead of the global random number generator.
  2. Initially it is set to None. When it is first accessed it will be initialized with a seed from random. This ensures that we respect any seeding that occurs before the first hypothesis test is run.
  3. We fix all of the places in our test suite where we call random.seed.

The third will be the fiddly bit. The first two should be relatively straightforward.

We may also optionally want to think about exposing this as a property that people can set. For example, if we exposed a hypothesis.global_random module attribute that people could set and we used that for everything, this would allow more fine grained control. However I think we don't need to do that to start with - we can just do the first bits and see if anyone complains.

@Zac-HD Zac-HD added the enhancement it's not broken, but we want it to be better label Oct 16, 2019
@alexjdw

This comment has been minimized.

@Zac-HD

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement it's not broken, but we want it to be better
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants