(🎁) Convert code to utilize pep 695

[KotlinIsland]

input:

from typing import TypeVar, TypeAlias, Generic

T = TypeVar("T", bound=float)
Foo: TypeAlias = str | T | None

class A(Generic[T]):
    ...

def f(t: T):
    ...

output:

type Foo[T: float] = str | T | None

class A[T: float]:
    ...

def f[T: float](t: T):
    ...

And also ParamSpec and TypeVarTuple.

[charliermarsh]

Yes, I'd love to support this. (It will take some time, need to start by supporting it in the parser and the semantic model.)

[zanieb]

This is ready to be worked on! I've started in #6289 but there is much more to do :)

[nathanwhit]

Hello! I'm interested in working on this, if that's okay!

I think I have enough to go on here to round out support for generic type variables, the only snag is with handling type variables that have explicit variance. If a type var has explicit variance, I don't see a way to translate it to the PEP-695 style and guarantee identical semantics. The issue is that the new syntax for generics doesn't have a facility to explicitly set the variance of a type variable, the variance is always inferred.

If we're adhering strictly to the spec (from my reading, at least), only TypeVar definitions with infer_variance=True should have inferred variance and are therefore definitely safe to upgrade to the new syntax. The trouble here is that I would guess that many TypeVar declarations in practice will not have that flag set, which might limit the usefulness of this rule.

If we're being a bit less strict, we could just assume that the variance inference will usually produce the same result, but I'm not sure how acceptable it is to potentially change the meaning of code.

[zanieb]

Hey @nathanwhit excited you're interested in working on this :)

We can use different applicability levels (#4183) to indicate our certainty that the fix will or will not change the meaning of the code. In this case, we could use an Automatic fix when infer_variance=True and a Suggested fix otherwise.

I've never seen someone set infer_variance=True before though 😬 maybe we can use a heuristic to infer if the variance would be the same?

[nathanwhit]

Thanks for such a quick response @zanieb!

We can use different applicability levels (#4183) to indicate our certainty that the fix will or will not change the meaning of the code. In this case, we could use an Automatic fix when infer_variance=True and a Suggested fix otherwise.

Makes sense!

I've never seen someone set infer_variance=True before though 😬 maybe we can use a heuristic to infer if the variance would be the same?

Now that I'm looking, infer_variance is new in PEP-695, so unless someone has partially upgraded for 695 they wouldn't have it set🙃. Yeah, a heuristic would be good (though I can't think of one off the top of my head 😬) since doing it properly is probably out of the question (since it requires a full typechecker).

--

A little awkward, but I dug deeper and I think we don't have to worry about variance for type aliases after all! It turns out that the variance of a type variable is actually ignored for type aliases, all that matters is the variance of the type variable used in the generic class. (This makes sense now that I'm thinking about it, since variance is a property of a generic type and generic type aliases aren't actual generic types, just new names for an underlying generic type).

For example:

from typing import Generic, TypeVar

T = TypeVar("T", covariant=True)

class Covariant(Generic[T]):
    pass

S = TypeVar("S", contravariant=True)
Co = Covariant[S]

class MyInt(int):
    pass

foo: Covariant[MyInt] = Covariant[MyInt]()
bar: Covariant[int] = foo

This typechecks despite the fact that S (used by the Co type alias) is defined as contravariant, because all that matters is the variance of T (the var used in the actual generic class).

So I think we can safely ignore the variance of a type var used in a type alias. Variance will be relevant again when we support upgrading classes to the new syntax (class List(Generic[T]): to class List[T]) though.