** 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. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...