Although this isn’t the first time this has been proposed, I (still) would really like to see this become a thing. It’s no exaggeration to say that this could at least half the number of overloads in the numpy stubs and scipy-stubs.
For bookkeeping, here are some of the related discussions:
- Make `@overload` less verbose - #10 by jorenham
- What would it take to implement type mapping for generics?
- false positive with `divmod` and overloaded `__divmod__` · Issue #9835 · microsoft/pyright · GitHub
In particular, the syntax I (informally) proposed in Make `@overload` less verbose - #10 by jorenham could be worth taking into consideration.
But to be honest, I don’t care much about the choice of syntax. Fancy stuff like this case type can just as well be added at a later point as far as I’m concerned.
I think that the straightforward functional API you propose here would be quickest and least bumpy road to success. The class-based syntax seems unnecessary to me.
Also note that this generalized “TypeVar with constraints”, since e.g. AnyStr can also be written in terms of TypeMap("StrMap", {str: str, bytes: bytes}). So with this, we’d also be able to resolve the concerns regarding the clashing PEP 695 syntax for contrained type variables and Idea: Simpler and More Expressive Type Annotations
It might be worth to also specify the behavior in case of subtyping/assignability, e.g. what’ll happen if you map bool according to {int: A, bool: B, Any: C}, and other ambiguous situations like this.
Also, why did you go with (str, bytes): bool and not str | bytes: bool? I think the latter would be more natural, and will avoid a syntax clash with Idea: Simpler and More Expressive Type Annotations.