GH-103721: Allow defining GenericAlias-like things

[adriangb]

• Issue: Allow defining GenericAlias-like things #103721

[AlexWaygood]

Two PEP8 nits:

[AlexWaygood]

Two more small comments below (wrap to 80 chars for .py and .rst files, use Sphinx markup to link to the rest of the docs).

In general, I think this is a reasonable feature to implement, but I think it should probably be documented somewhere in typing.rst.

[sobolevn]

I am -1 on this, because it can backfire for a lot of tools that rely on the fact that {types,typing}.GenericAlias (and nothing else) represent generic types.

For example, https://github.com/HypothesisWorks/hypothesis/blob/e33377305225df0a4ee50a1bd55ed801df6d1ea2/hypothesis-python/src/hypothesis/strategies/_internal/types.py#L298 (and in many other places).

I think that this needs more visibility and discussion before getting accepted.

[adriangb]

Would those things backfire any more now than they currently do? Clearly, this PR doesn't make everything automatically work for every library. Anything that is currently doing introspection and trying to detect typing.GenericAlias (which is sort of a private thing, only mentioned once in passing in typing.rst) would need to add some sort of _is_generic_alias_like check or special case the particular library (Pydantic already has a Hypothesis plugin). But I don't think that makes things worse than the current status quo.

The best alternative to the current implementation/proposal I can think of is to make this stuff more "public" by providing a Protocol, exporting a public is_generic_alias_like function, or making GenericAlias subclassable. Then things like Hypothesis would "just work", which is I think what you want. I feel that the barrier for that is much higher since GenericAlias is this semi-private mostly undocumented thing.

[JelleZijlstra]

Let's keep broader discussion about whether this is a good idea to the issue, not this PR.

[Zac-HD]

I am -1 on this, because it can backfire for a lot of tools that rely on the fact that {types,typing}.GenericAlias (and nothing else) represent generic types.

For example, HypothesisWorks/hypothesis@e333773/hypothesis-python/src/hypothesis/strategies/_internal/types.py#L298 (and in many other places).

Hypothesis only uses GenericAlias in our has_type_arguments(), is_generic_type(), and "is from the typing module" predicates. , so I think this is very unlikely to be a problem for us. So long as there's some way to inspect at runtime, I can maintain the various code paths just fine 🙂

More generally, I never want Hypothesis doing something bizzare internally to be a blocker for upstream improvements. I'm perfectly comfortable with typing._GenericAlias breaking my code; it's even got the _-prefix to mark that I should expect that!

[adriangb]

It seems like improving docs around subclassing types.GenericAlias as well as maybe improving some of the ergonomics of subclassing it is the path forward here, so I'm going to close this PR at least for now. Discussion can continue in the issue.