How to create TypeVar that is either a subclass of A or a subclass of B ?

[randolf-scholz]

Consider the case when we want a TypeVar named X that is either a subclass of A, or a subclass of B.

How can this be realized using typing & checking with mypy ????

Neither X=TypeVar("X", bound=Union[A,B]) nor X = TypeVar("X", A, B, covariant=True) seem to do the right thing (see example below).

Minimal Working Example

from __future__ import annotations
from typing import *

SelfA = TypeVar("SelfA", bound="A")
SelfB = TypeVar("SelfB", bound="B")

# fmt: off
class A:
    def __add__(self: SelfA, other: SelfA) -> SelfA:  return self
    def __radd__(self: SelfA, other: SelfA) -> SelfA: return self

class B:
    def __add__(self: SelfB, other: SelfB) -> SelfB:  return self
    def __radd__(self: SelfB, other: SelfB) -> SelfB: return self

class SubA(A): ...
class SubB(B): ...


T = TypeVar("T", bound=A)
class Foo(Generic[T]):
    s: T
    def __init__(self, x: T, y: T):
        self.s = x + y                   # ✔

foo_a: Foo[A] = Foo(A(), A())            # ✔
foo_b: Foo[A] = Foo(SubA(), A())         # ✔
foo_e: Foo[SubA] = Foo(SubA(), SubA())   # ✔


AuB = TypeVar("AuB", bound=Union[A,B])
class Bar(Generic[AuB]):
    s: AuB
    def __init__(self, x: AuB, y: AuB):
        self.s = x + y                   # ✘ raises type[assignment, operator]

bar_a: Bar[A] = Bar(A(), A())            # ✔
bar_b: Bar[A] = Bar(SubA(), A())         # ✔
bar_e: Bar[SubA] = Bar(SubA(), SubA())   # ✔


AB = TypeVar("AB", A, B, covariant=True)  # covariant=True does nothing?
class Baz(Generic[AB]):
    s: AB
    def __init__(self, x: AB, y: AB):
        self.s = x + y                   # ✔

baz_a: Baz[A] = Baz(A(), A())            # ✔
baz_b: Baz[A] = Baz(SubA(), A())         # ✔
baz_e: Baz[SubA] = Baz(SubA(), SubA())   # ✘ raises type[assignment, type-var]
# fmt: on

using python=3.10.6 and mypy=0.971.

[erictraut]

A bound TypeVar won't work in this case if you expect x + y to type check because x and y are both of type A | B (or subtypes thereof), and __add__ is not supported for mismatched combinations of A and B operands.

A constrained TypeVar should work in this case. Mypy appears to have a bug here on the line that begins with baz_e:. This type checks without errors in pyright. (Incidentally, you're using a very old version of mypy. I checked with the latest version, but the bug still persists.)

[erictraut]

it'll complain about just baz_e: Baz[SubA] even in the absence of assignment

Ah, I didn't realize that. Yes, then I agree that mypy is being self-consistent here, and it sounds like there was some justification for this. Perhaps @JukkaL or @gvanrossum remember the reasoning. I can't think of any type consistency justification for this limitation, but I could be missing something.

If that limitation is intended, then it appears there's no solution to the problem OP posed.

[JelleZijlstra]

I believe mypy is correct. Consider this code:

from typing import AnyStr, Generic

class SubStr(str): ...

class Baz(Generic[AnyStr]):
    s: AnyStr
    def __init__(self, x: AnyStr, y: AnyStr):
        self.s = x + y

baz_e: Baz[SubStr] = Baz(SubStr(), SubStr())
reveal_type(baz_e.s)

Pyright throws no errors and infers SubStr on the last line, but at runtime, baz_e.s is a str, not a SubStr.

[erictraut]

Actually, pyright reveals the type of baz_e.s on the last line as str, not SubStr, so that's consistent with runtime behaviors.

[randolf-scholz]

So what to do in this case? Should I open a feature request? Because this is something that actually comes up quite often, at least in the kind of data-wrangling code I'm working with.

[erictraut]

Here are some options:

1. Change your code to avoid this usage pattern.
2. Use # type: ignore to suppress errors emitted by mypy.
3. File a bug report with mypy and try to convince its maintainers that Baz[SubStr] should be supported. Then push for this change to be prioritized or submit a PR yourself.
4. Use pyright to type check your code. (This isn't an option if your code is part of a published library because it then needs to work with all type checkers including mypy.)
5. Propose and champion a change to the Python type system. This could be a clarification of how a constrained TypeVar should work in your code sample above. Or it could involve some new extension to the type system. In either case, the typing-sig email list is probably the best place to start that discussion, since the broader typing community would need to be convinced of its merits.