On Mon, Jan 27, 2020 at 3:05 PM Saul Shanabrook via Typing-sig <typing-sig@python.org> wrote:
Ah, I seem to have not added a name to my account, it should be fixed now.

Your email is still weird (b9f0h8l2g1i9f8g9@quansight.slack.com).
 
I don't see how you would be able to do the same work-around though for `__init__`, to allow the `MyCustomClass[int]()` to be differentiated at runtime from `MyCustomClass[str]()`

This (what you wrote in your first post) is an interesting feature request, but I'm not sure how to implement it in C.

Also there's the issue that PEP 585 argues (IMO convincingly) that for instances the generic parameters are erased, so that list[int]() returns a plain list instance, indistinguishable from list(). Now, class methods can be invoked from instances too -- if I write {}.fromkeys(range(10)) that's the same as dict.fromkeys(range(10)). But in the first call  the __origin__ and __parameters__ attributes are unavailable (due to the type erasure). And I don't think we should reconsider the type erasure.
 
Was it discussed somewhere why generic type are not implemented as metaclasses? It seems like if they were, then you would be able to do this, by simply taking `type(self)` to give you back the generic type. Also, from a conceptual perspective, if I squint my eyes, generic classes seem like they should be metaclasses, since they are basically functions that return classes, just with a different syntax than normal function calls for stylistic purposes.

This was answered by Elazar already, and to reiterate, if list isn't a metaclass, then list[int] shouldn't be either -- instantiating either returns a list object.
 
--
--Guido van Rossum (python.org/~guido)