-
PEP 695 states that traditional type vars are compatible with the new syntax, take this example: K = TypeVar("K")
@dataclasses.dataclass
class Container[K: Literal["my_lit", "my_lit_2"]]:
key: K In this case, I have the desire to manually control the variance, but it would be nice to avoid inheriting from Take this example, where I want to have less specific literal overloads: from typing import Generic, Literal, TypeVar, overload
import dataclasses
K = TypeVar("K", covariant=True)
@dataclasses.dataclass
class Container[K: Literal["my_lit", "my_lit_2"]]:
key: K
@overload
def foo(
arg_1: Container[Literal["my_lit"]],
) -> None:
print(arg_1)
@overload
def foo(
arg_1: Container[Literal["my_lit_2"],],
) -> None:
print(arg_1)
def foo(arg_1: Container[Literal["my_lit", "my_lit_2"]]) -> None:
print(arg_1) Here, K is still treated as invariant, and in order to change that I would have to inherit from Perhaps this partial compatibility purely exists so that you can reuse the same TypeVar name with old/new syntax, but was curious if this was intended behavior, or not? TypeVars are probably always going to exist in the language, due to the need to tweak variance, but it would be nice to still avoid inheriting from |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
In your example, the you are defining two symbols When you define a class, you need to either use PEP 695 syntax or traditional TypeVars. You cannot combine the two. The PEP is very clear on this. |
Beta Was this translation helpful? Give feedback.
In your example, the you are defining two symbols
K
in two different scopes. They have no relation to each other.When you define a class, you need to either use PEP 695 syntax or traditional TypeVars. You cannot combine the two. The PEP is very clear on this.