@erictraut @gvanrossum I pushed a few more changes; please take a look.

I am also considering adding more information about the implementation technique I'm currently using (a dummy immediately evaluated function, which I just learned is "lambda lifting"), but I'm not sure we need to specify that in the PEP.

Submitted python/steering-council#186 to the SC to approve these changes. Marking as "DO-NOT-MERGE" until the SC approves.

Could you include the small AST change for TypeAlias.name here as well?

Couldn't comment inline unfortunately. It should be here:

- TypeAlias(identifier name, typeparam* typeparams, expr value)
+ TypeAlias(expr name, typeparam* typeparams, expr value)

Pushed another change related to name mangling (I realized that the wording in the PEP would require severe complications in the symtable).

Does the mangling change mean that inner scopes cannot refer to that type parameter without generating a runtime exception?

class Foo[__T]:
    def method(self, val: __T): # Does this work?
        x: __T = val # Does this work?

@erictraut yes, that will work. (Though note that the annotation within the function will always work without a runtime exception, because annotations on locals are never evaluated.) The name is mangled at both the definition site and all usage sites within the class. This was quite easy to implement: python/cpython@bd49622.

The PEP previously proposed not mangling the TypeVar names. That would require deep changes to the symtable to track whether a name refers to a TypeVar. The new proposed approach is more consistent with the rest of the language: names that are syntactically within a class are always mangled.

I think there are very few ways the mangling is even visible to user code. The only way I can think of is this:

>>> class A: pass
... 
>>> class Foo[__T](print(locals()) or A): pass
... 
{'_Foo__T': __T, '.generic_base': typing.Generic[__T], '.type_params': (__T,)}

It still isn't clear to me which of the def695 "functions" exist to provide scopes for type variables, and which are to support lazy evaluation. Are the semantics of both identical?

Yes, they have identical semantics. Let me push something to make that explicit.

The SC approved the proposed changes.

For reference: python/steering-council#186 (comment)