Provide SearchStrategy optionals

[MaxG87]

I noticed that I frequently write my own helper optionals:

_T = TypeVar("_T")
def optionals(strategy: st.SearchStrategy[_T]) -> st.SearchStrategy[Optional[_T]]:
    return st.one_of(st.none(), strategy)

Obviously, I use it to generate values for variables that either take a value or are None.

I wanted to ask if this coud be part of the strategies submodule. Then I could stop to copy that implementation from project to project. I expect it to be helpful for others too.

[rsokl]

Given that the shorthand

st.none() | strategy  # equivalent to `st.one_of(st.none(), strategy)`

is already available to express this, I wouldn't think adding optionals() to the API is warranted.

That being said, I do notice that st.none() | strategy doesn't have the desired type annotation associated with it - it gets resolved as SearchStrategy[None].

@Zac-HD do you think adding an overload for the case of a two-argument invocation of one_of would be useful in terms of providing more accurate type annotation resolution for the | syntax?

(IGNORE ALL OF THE BELOW - MY IDE WASNT CONFIGURED CORRECTLY)

Also, an aside...

As I was playing with @MaxG87 's optionals implementation, I noticed some weird behavior from pylance...

Any idea why the above signature might produce this confused annotation, @Zac-HD ? Perhaps something for us to point out to the pyright folks.

[MaxG87]

The proposed shorthand is good for a single usage but cannot be reused. Having the optionals strategy would allow

@given(st.optionals(st.text()), st.optionals(st.integers()))
def test_can_handle_missing_info(name, age):

If I had to use the shorthand, I either would have to duplicate the logic or predefine things like maybe_text = st.none() | st.text() everywhere where needed. It also would not be very flexible. For example, I cannot control the length of maybe_text directly, let alone character strategies.

A very weak argument at last: The easiness of st.just(None) did not hinder the introduction of st.nones().

[Zac-HD]

A very weak argument at last: The easiness of st.just(None) did not hinder the introduction of st.nones()

It also predates our API design guide, so. I'd still be inclined to accept it on the basis that None really is specially common, but there'd be an argument against now too.

Why the confused annotations?

Looks like SearchStrategy.__or__ is not annotated! I'll open a PR with type hints for that and st.one_of() 😁