TypeVars with constraints in other languages

[JelleZijlstra]

We support this form for creating TypeVars:

A = TypeVar('A', str, bytes)

I haven't encountered this sort of thing in other languages that support type variables. For example, TypeScript only supports a form that looks equivalent to our bound= (although confusingly they call it a constraint).

Are there other languages that support this feature? I'm asking because the way this kind of TypeVar behaves isn't very intuitive to me, so I'd like to see how other languages handle it.

[sobolevn]

I don't know any. I also think that this is a very problematic piece of code.

1. I don't know any reasonable use-cases except AnyStr
2. I think that this feature predates @overload that can do pretty much the same thing
3. It is hard to teach (because this concept is new, while bound= is good, because it is known from other languages by some people)
4. I know a lot of bugs in mypy that are caused by this

I would really like to see it removed! 🙏

[AlexWaygood]

Even AnyStr could be redefined using bound: AnyStr = TypeVar("AnyStr", bound=str|bytes)

EDIT: Actually, ^that doesn't have exactly the same semantics, because there might be situations where the TypeVar isn't narrowed to either str or bytes, and the inferred type remains str | bytes... with constraints, the TypeVar has to be inferred as either str or bytes; it can't be inferred as the union type.

[Gobot1234]

I use constraints in an AnyStr-like way a lot in my code removing it would make a lot of my code untype-checkable and cause me a massive headache

[sobolevn]

(I understand that this won't be removed, but I just express my non-actionable feelings about it)

[AlexWaygood]

I agree that the way this kind of TypeVar behaves seems unintuitive to me, and generally less useful that TypeVars with the bound keyword argument. It always seemed strange to me that PEP 484 talks about TypeVars with constraints in depth, but appears to treat the bound argument as an afterthought.

[JelleZijlstra]

The current docs do that too: https://docs.python.org/3.10/library/typing.html#typing.TypeVar. Maybe we should change them to focus more on bound=.

[AlexWaygood]

I have created https://bugs.python.org/issue46769

[Akuli]

Bad documentation might be why I wrote this broken code before learning about bound:

# _FileTabT represents a subclass of FileTab. Don't know if there's a better
# way to tell that to mypy than passing FileTab twice...
_TabT = TypeVar("_TabT", "Tab", "Tab")
_FileTabT = TypeVar("_FileTabT", "FileTab", "FileTab")

I'm not sure whether I was reading the docs or the PEP when writing that. Probably the PEP, to be honest.

[JukkaL]

On Wed, Feb 16, 2022 at 3:40 PM Alex Waygood ***@***.***> wrote: Even AnyStr could be redefined using bound: AnyStr = TypeVar("AnyStr", bound=str|bytes)

This is subtly different from the current definition of AnyStr -- AnyStr only allows str or bytes as values, but not subclasses of str or bytes, whereas using a bound also allows subclasses. The AnyStr value restriction is needed to precisely model certain nuances of stdlib functionality. For example, this function doesn't type check correctly with a union bound, since concatenating a string to an instance of an arbitrary str subclass produces a str: def concat(x: AnyStr, y: AnyStr) -> AnyStr: return x + y # Only okay with the current definition with AnyStr class S(str): pass concat(S(), 'x') # Result is 'x' (str instance, not S instance) Of course, we could also use @overload, though that would be more verbose and type checking wouldn't be as precise (but probably good enough). AnyStr was added quite early in the development of the typing module, and the primary motivation was to support IO[AnyStr], Match[AnyStr] and Pattern[AnyStr]. These work with str or bytes, but they don't properly support subclasses of str/bytes. For example, IO[S] where S is a subclass of str doesn't quite make sense. Maybe it would have been better to use union bounds, even if they are arguably somewhat incorrect, but it would probably be too disruptive to change this now. When AnyStr was added, we didn't even have union types! I think that documentation shouldn't emphasize AnyStr, since the use cases where it actually is better than an overload/union are quite rare, at least outside the stdlib. Very often people use it incorrectly. Even in the stdlib stubs most uses of AnyStr should perhaps be replaced with overloads. AnyStr makes some signatures more compact, but it's often used pointlessly in cases where str|bytes would be better. JukkaMessage ID: <python/typing/repo-discussions/1080/comments/2189618@ github.com>

…

[AlexWaygood]

This is subtly different from the current definition of AnyStr

Yes, I remembered as much almost instantly after posting my message 🤦‍♂️