On Mon, Jun 27, 2022 at 11:51 PM Eric Traut <eric@traut.com> wrote:
The good news is that I think I've come up with a solution that addresses all of the requirements, doesn't add significant complexity to the compiler, and shouldn't have any compatibility impact on debuggers. The key is to abandon the requirement that every reference to a type variable "T" refer to the same object. Instead, I have the compiler generate code to construct a new "type var proxy" object each time "T" is referenced. Since type variables are typically referenced only in type annotations (which are evaluated once — or never if "from __future__ import annotations" is in effect) and in specialized base classes, I'm not concerned about the runtime overhead of allocating one of these objects each time.
I haven't thought through this carefully, but this seems to solve all the concerns with runtime semantics that haven been raised. The main compromise seems to be that expressions that refer to type variables, such as "cast(list[T], x)", will be a bit slower? In my experience these are rare and the performance impact should be totally acceptable. This adds a new kind of namespacing concept to Python, but this seems justified to me, since the alternative ways of achieving the desired semantics (of which there seems to be little doubt) are much more complicated.
I've updated the draft PEP to reflect these changes. I've also made the following additional changes based on feedback: 1. I've scaled back the proposal and removed sections on "default type arguments", explicit specialization of generic functions, and recursive type aliases. These can be covered in other PEPs. 2. I've switched from an "extends" keyword to a simple colon when specifying the upper bound or the constraints for the type variable. This feels more Pythonic.
I like these updates! I think that the PEP looks more streamlined and fits in better with the rest of the language now. The PEP could perhaps be more convincing to people outside the typing community if there were more examples extracted from real-world projects. Also, what about adding statistics about how often type variables and generic classes and protocols are used? Finally, have you asked for feedback from some more typical users of typing (that are not active on typing-sig and don't work on type checkers)? In particular, maybe it would be helpful to present the PEP to developers who use type annotations for runtime purposes, and to ask if they have concerns about the runtime semantics. The feedback could then be summarized in the PEP. I'm not sure if this is commonly done in PEPs, but it could be helpful here since a lot of developers still don't use type annotations regularly (or at all). Jukka