Thanks @hauntsaninja for taking a look.

I'm guessing because use of the type alias from outside the class would not make sense.

But I find it to make perfect sense, because it's bound by the class. Naturally, Finder[int].Pattern is Union[int, Wildcard] and Finder.Pattern is Union[Any, Wildcard].

In essence, I don't understand why the type variable is not functionally equivalent to a concrete type within the class.

As a workaround, you could define a generic type alias and then bind that generic type alias to the type variable.

Something like that is indeed what I am doing, but I find that such type aliases directly in the class would make for much cleaner code.

This isn't supported for the same reason that you can't use outer-scoped (bound) type variables for inner-scoped class definitions.

from typing import Generic, TypeVar
T1 = TypeVar("T1")
T2 = TypeVar("T2")
class Foo(Generic[T1]):
 class Bar(dict[T1, T2]): # pyright: T1 is already used by an outer scope
 ...
 reveal_type(Bar()) # mypy: test10.Foo.Bar[Any, Any]

Pyright emits an explicit error in this case. Mypy does not, but it also doesn't handle the case as you might expect. It simply treats T1 as if it's Any.

Until recently, Python type checkers were inconsistent about whether class-scoped type aliases should be allowed. PEP 484 (which introduced the notion of type aliases) and PEP 613 (which introduced TypeAlias) are quiet on this topic. The maintainers of the major type checker came to an agreement that type aliases should be allowed within classes but not within functions.

What you're doing here (attempting to define a class-scoped type alias that uses an outer-scoped bound type variable) is not supported by Python type checkers today. I think it would be an uphill battle to convince all of the type checkers to add such support because it would require a bunch of extra logic (e.g. to handle specialization for member access expressions that are accessing the class-scoped type alias from outside the class — e.g. Finder[int].Pattern in your example) and because this is such a niche use case.

Thanks @erictraut, I understand what you are laying out here in the general case, but maybe not in the specific case which I am describing, since the type checker is already able to figure out the type in Finder[int]().Pattern.

I'm not understanding what the problem is with @ntessore's example either. This seems pretty well defined to me? (edit: bad word choice; if it's not defined in any PEP then it's literally not defined; what I meant was it seems to have one clear & straightforward expected result.) I only made it to googling and writing this when this little experiment almost worked (I was very surprised the Foo.T syntax worked at all, but then didn't allow U).

class Foo(Generic[FValue]):
 T: TypeAlias = int
 # U: TypeAlias = FValue # the mypy error under discussion
CoolT: TypeAlias = Foo.T
X: CoolT = 4
# Y: CoolT = 'string' # properly gets 'incompatible types' error

My use-case is I'm trying to write an interpreter, which seems to be the worst spot of benefiting immensely from type hints (otherwise stupid subtle bugs everywhere forever) but the number of generics needed makes the code pretty much unreadable. @ntessore's example is exactly what I'd love to use here. My 0ドル.02