Conditional use of classes with differing parameters

[injust]

Code sample in pyright playground

from __future__ import annotations

import random
from enum import Enum, auto


class Kind(Enum):
    ONE = auto()
    TWO = auto()


class Item:
    def __init__(self, kind: Kind | None) -> None:
        self.kind = kind


class ItemKindTwo(Item):
    def __init__(self, kind: Kind = Kind.TWO) -> None:
        super().__init__(kind)


kind = random.choice([Kind.ONE, Kind.TWO, None])
item_cls: type[Item] = Item
if kind == Kind.TWO:
    item_cls = ItemKindTwo
# if item_cls is ItemKindTwo, then kind cannot be None
item_cls(kind)  # Argument of type "Literal[Kind.TWO, Kind.ONE] | None" cannot be assigned to parameter "kind" of type "Kind" in function "__init__"

Pyright errors and says that None cannot be passed to ItemKindTwo. But if kind is None, then item_cls must be Item, not ItemKindTwo.

Is it possible for Pyright to understand this? mypy seems to have no problem with it.

[erictraut]

Pyright is working as designed here, so I don't consider this a bug.

Static type checkers perform "type narrowing" of expressions based on type guards. Each expression is narrowed independently from other expressions. For example, the type guard kind == Kind.Two narrows the type of expression kind. It does not narrow the type of other expressions such as item_cls. This would require the type checker to retain some form of conditional type such as "the type of x is A if the type of y is Z but the type of x is B if y is not Z". Not only would that be computationally infeasible to track for complex code flows, it would also be almost impossible to explain in error messages.

For more details about type narrowing and type guards, refer to this documentation.

The reason that mypy does not (currently) generate an error here is a quirk of mypy. In many circumstances, it uses a "join" operation rather than a "union" operation when evaluating types. In your code sample, it's "joining" the types Item and ItemKindTwo into the type Item when evaluating the type of item_cls. The constructor for Item is callable with a None argument. However, mypy is giving you a false negative here because the constructor for ItemKindTwo does not allow an argument of None, so it appears that there is no type violation.

Pyright uses unions rather than joins, so it evaluates the type in your example to be Item | ItemKindTwo. Mypy maintainers have been steadily working to replace their use of joins with unions (there are still 45 open bugs on the topic), so your code will likely fail type checking in a future release of mypy. For more details about joins versus unions, refer to this documentation.

One issue here with your code is that you're violating the Liskov Substitution Principle (LSP) because the __init__ method for ItemKindTwo is not compatible with (or more formally, "not assignable to") the __init__ method of its parent class. This is not uncommon in Python code, so there is a convention among type checkers to exempt the __init__ method from LSP override violations, but it's still a practice that I try to avoid in my own code. With this context in mind, you can make your code type check by changing it as follows:

class ItemKindTwo(Item):
    def __init__(self, kind: Kind | None = Kind.TWO) -> None:
        super().__init__(kind)