Should non-generic classes with `__class_getitem__` be subscriptable in a type expression?

[jorenham (Joren Hammudoglu)]

@carljm

I think the full version is a significant increase in the complexity of what can be represented in type annotations, and brings a lot of power to customize the syntax and expressiveness of type annotations. Combined with PEP 747, it effectively gives the full expressive power of Python itself to writing type expressions (as long as you wrap it in a subscript). Used well, this can potentially make some annotations less verbose and nicer to read.

I had Claude Opus 5 investigate exactly how much it could simplify in NumPy’s bundled stubs and in scipy-stubs. After grinding at it for a while, it concluded:

numpy ~52-59%, scipy-stubs ~38-43% LOC reduction. Both lose ~2/3 of their @overloads.

(full session)

This seems very plausible to me. These are not small gains either, because e.g. scipy-stubs currently counts 97,945 LOC (according to scc, excluding comments and whitespace, and excluding type-tests).

@carljm

The downside is that it can also make type annotations a lot harder to read.

I’d argue that these overload-heavy stubs are significantly harder to read than what they’d look like if they could be simplified using these type constructors.

Also note these are simplications that could be done without the literals extension. Those I’m mostly interested in to make shape-typing more ergonomic for downstream users. So it’s something that would certainly be very nice to have, but without it I’d already be very happy to say the least.