** I would really like a response from Łukasz, the PEP author. **
I accidentally started a thread with a similar subject but accidentally "PEP 505" instead of "PEP 585".
A quick summary of points from that email to which I'm not returning below:
- The proxy type will have a name: types.GenericAlias.
- list == list[str] should be false.
- isinstance([1, 2], list[int]) should raise TypeError.
- Make re.Pattern, re.Match, io.IO generic.
- I don't know whether we should make typing.List be the same object as builtins.list or not (and ditto for all generic classes in typing).
- I'm stuck making type[int] work (this is needed so builtins.type[x] works like typing.Type[x]).
A few other simple points:
- Let's disallow isinstance(x, list[int]) and issubclass(C, list[int]).
- We are making re.Match, re.Pattern and io.IO generic.
Since that thread I've got some more ideas.
1. We should rename __parameters__ to __args__, there's no reason to deviate from typing.py here.
2. We can relatively easily add a new __parameters__ attribute (lazily computed) that returns only the subset of __args__ that are type vars, and make it so that e.g. dict[str, T][int] works (and returns dict[str, int]) and list[int][int] is disallowed. This is what __parameters__ means in typing.py. It will fix 2 out of the 3 current test_typing.py failures.
3. We *could* easily change GenericAlias.__call__ to set __orig_class__ on the new instance if it works, ignoring the error (e.g. if the class uses __slots__ or overrides __setattr__), but I see a downside: it adds an extra entry to self.__dict__ for each instance. While typing.py currently does this (and there's a test for it), I think it's a high cost to pay for making a class generic. And the purpose of `__orig_class__` is questionable -- why have it at all? (This is the third failure in test_typing.py -- if we decide not to do this, we should disable the failing parts of that test.)
4. We should probably arrange for list[int] == list[int] by defining GenericAlias.__eq__. (But list != list[int].)
5. Should we touch typing.py at all? Or just leave it be? Though the proposed silent deprecation will encourage people who *want* to do runtime introspection to ignore the changes, and then they will be in for a bad surprise 5 years hence.