I might have been misunderstanding this change. This `Proxy` class you are making, is that used only for built in collection or for all generic classes?
That's still open. PEP 585 hasn't been sufficiently discussed. But I note that none of your examples work with the current typing.py module, so in a sense we're not breaking anything if we were to use the much simpler class I'm implementing in C (tentative name GenericAlias -- though PEP 585 doesn't name it). Also note that the Python code I attached earlier is irrelevant at this point.
For example, I would like to know the type parameters pass in at runtime to my custom generic class:
```
class Maybe(typing.Generic[T]):
@classmethod
def nothing(cls) -> Maybe[T]:
# Should be able to tell in here if `cls` had generic parameters added
...
@classmethod
def just(cls, value: T) -> Maybe[T]:
...
# So that we can create different instances based on type
assert Maybe[int].nothing() != Maybe[str].nothing()
```
Another use case here is for collections that do require knowing the inner type value at runtime, like NumPy's arrays. Although NumPy might
not change it's syntax, it would be nice for more modern array libraries to be able to specify the inner types as type parameters, instead
of as arguments, so they can be checked statically as well as used at runtime. So something like this `numpy.ndarray[numpy.float64].arange(10)`. Ideally, we would also be able to do the same in the constructor, to allow something like `numpy.ndarray[numpy.float64](1, 2, 3)` to create an array of floats.
This should be a separate discussion, since you are very much proposing a new feature. It will require a separate PEP. I do appreciate the desire! We just need to get other people to agree that it's desirable *and* can be implemented reasonably. Then we can work on a PEP and reference implementation.