Structural difference between sampled_from and one_of: motivation and possible unification?

[vreuter]

I feel it's a bit confusing and suboptimal UX that sampled_from (choosing from elements) and one_of (choosing among generators of elements) force different structures for their arguments and therefore "feel different" at the call site. Typically when I want to generate values, I'm thinking "here, blackbox randomisation enginge, are some alternative sources of values I want to generate", and would like to not need to think always about whether those sources are actual individual elements or are generators of them. The structural difference b/w these two functions (sampled_from and one_of) forces this awareness.

OTOH, I guess this makes sense given that for one_of the probability distribution of the outcomes actually depends on the sequence of the arguments it's given. OTOH, there's the forced (bad, IMO) UX described above, when there doesn't necessarily need to be and the experience of using either strategy could be unified.

Is there additional motivation, besides pushing the programmer to recall the probability distribution effect of argument ordering in one_of) for the difference in the structure of these two functions' respective arguments? I guess perhaps there's thought that element collections (to sampled_from) may often be huge and someone wouldn't want to enumerate the domain, whereas with one_of the programmer would more typically be using a quite finite number of generators?

Is there any thought about unifying the UX for these two API members?

[vreuter]

Similar to motivation of having opened #3819

[Zac-HD]

Typically when I want to generate values, I'm thinking "here, blackbox randomisation enginge, are some alternative sources of values I want to generate", and would like to not need to think always about whether those sources are actual individual elements or are generators of them. The structural difference b/w these two functions (sampled_from and one_of) forces this awareness.

I think forcing this awareness is in fact desirable - elements and strategies are fundamentally different things, and there are multiple places where guessing which the user wants is just not going to work (as noted here).

You can pass a sequence of values to either though, so I don't think there's much more to be done here. (we can't accept st.sampled_from(*args), because a single-argument collection would then be ambiguous)