Skip to content

Clarify our concept of "the current settings", and refactor #4597

Description

@Zac-HD

This issue was prompted by and blocks #4563, but I'd want to fix it anyway.

Our settings() class is honestly pretty good considering the history, but the current design is still pretty dubious in places which deal with global state: specifically, we have both a global notion of "current profile", and can override that for a test function decorated with @settings(...). So:

  • settings() should give you "the current settings", inclusive of the effects of a decorator on the current test, if any.
    • I think we can make this change immediately, without any deprecation period. We'll need to have settings know about BuildContext, and in future maybe also 'the backend for this test case' to handle ObservabilityConfig, but that seems okay to do in the constructor.
    • settings.get_profile(settings.get_current_profile_name()) already works, if that's what you actually wanted.
  • To avoid confusion, let's deprecate registering a new profile from inside an active test. I'd make it an error immediately to register a new profile while the current settings differs from the current settings profile, since that seems overly error-prone.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementit's not broken, but we want it to be betterlegibilitymake errors helpful and Hypothesis grokable

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions