Extend PEP 695 generic class and function rules

[ntBre]

Follow up tasks from #15565

• Handle generic methods
• Handle default kwargs for Python >= 3.13
• Unquote type variable forward reference annotations (see below)
• Handle TypeVarTuple generics with Unpack instead of *: class MultipleGenerics(Generic[S, T, Unpack[Ts], P]): ... ¹
• Allow multiple base classes for generic classes ([pyupgrade] Handle multiple base classes for PEP 695 generics (UP046) #15659)
• Use string replacements for UP040's autofix too, instead of using the ExprGenerator ([pyupgrade] Reuse replacement logic from UP046 and UP047 (UP040) #15840)
• Rename private type variables in generics (don't make inline generics like [_T]) ([pyupgrade] Rename private type parameters in PEP 695 generics (UP049) #15862)

Related: #4617, #12542

Footnotes

1. https://github.com/astral-sh/ruff/pull/15565#discussion_r1925489033 ↩

[AlexWaygood]

One other thing that might be nice would be to unquote annotations. E.g. old-style type variables often need to quote their bounds if the bound needs to use a forward reference to a name not yet defined

from typing import Generic, TypeVar

T = TypeVar("T", bound="list[T | None]")

class Foo(Generic[T]):
    var: T

But the bounds for PEP-695 type parameters are lazily evaluated, so there's no need to quote forward references:

>>> class Foo[T: list[T | None]]:
...     var: T
...     
>>> Foo.__type_params__[0].__bound__
list[typing.Optional[T]]

[ntBre]

I started working on renaming private type variables, but I think it's a bit more complicated than I thought. At first I was just going to do the rename as part of DisplayTypeVar::fmt, but I realized that you have to be pretty careful not to change the meaning of other instances of the type you're renaming. For example,

class T: ...

_T = TypeVar("_T")

def generic(var: _T) -> _T:
    x: T = T()
    return var

You can't even just look at the signature or the parent scopes, you also have to look at the body of the class or function.

Even if you restrict the fix to variables not in the parent scope, you then have to update the name of the type in the body of the class or function too:

_G = TypeVar("_G")

class SafePrivate(Generic[_G]):
    var1: _G

This was the test case I was writing when I realized that I needed to rename the inner _G too, not just the one in the class signature. I found the Renamer API, which sounded very promising, but I'm running into some panics like this: assertion failed: start.raw <= end.raw, which I assume is because of the overlapping Edit::replacement from the existing UP046 code and the edits from Renamer::rename.

Would I need a separate rule to do the rename in a separate pass from the initial replacement? Or is there another approach I'm missing?

[AlexWaygood]

Would I need a separate rule to do the rename in a separate pass from the initial replacement? Or is there another approach I'm missing?

This might be quite a good solution. It would allow us to use the Renamer API (which I agree is the easiest, most robust way to do this!), and would also allow us to complain about e.g. handwritten PEP-695 classes that use TypeVars with leading underscores, which I think is a bit of a stylistic antipattern since they're private to the class by default. For this, though, I think it does make sense to have one rule that would rename type parameters in type aliases, functions and classes, rather than a separate rule for each. (That doesn't mean that they all have to be tackled in one PR, however!)

[AlexWaygood]

One other thing that might be nice would be to unquote annotations. E.g. old-style type variables often need to quote their bounds if the bound needs to use a forward reference to a name not yet defined

I suppose this could be done as an (initially preview-only) extension of UP037 and PYI020, rather than adding a new rule