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

Deprecate the max_shrinks setting #1235

Closed
Zac-HD opened this issue Apr 14, 2018 · 0 comments · Fixed by #1330
Closed

Deprecate the max_shrinks setting #1235

Zac-HD opened this issue Apr 14, 2018 · 0 comments · Fixed by #1330
Labels
bug something is clearly wrong here legibility make errors helpful and Hypothesis grokable

Comments

@Zac-HD
Copy link
Member

Zac-HD commented Apr 14, 2018

As discussed in #535, the max_shrinks setting is a mess. There's no way to pick a meaningful value for it beyond "none, default, lots". For "none" it's actually better to disable shrinking using the phases setting, because max_shrinks=0 behaves identically to max_shrinks=1.

The setting should be removed; max_shrinks=0 translated to phases=tuple(Phase)[:Phase.shrink] (deliberately changing behaviour to match expectation).

It would be nice to have an improved heuristic for shrinking - aiming to fully shrink large examples, but bail out of pathological cases quickly - but for the first pass we can simply hard-code the current default behaviour. A second pass should consider #233.

master...Zac-HD:no-max-shrinks is an updated copy of the work I did in #1211 before giving up; the tests almost all pass but there are a few that depend on the one shrink/no shrinks distinction and can't afford the perf cost of shrinking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug something is clearly wrong here legibility make errors helpful and Hypothesis grokable
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant