PEP 695: Lazy evaluation, concrete scoping semantics, other changes #3122
Conversation
- Lazy evaluation means that referencing a later type variable works at runtime - Disallow walrus in TypeVar bounds, and also disallow yield/yield from/await in the same contexts
|
@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 Couldn't comment inline unfortunately. It should be here: Line 802 in 63a594f - 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,)} |
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Yes, they have identical semantics. Let me push something to make that explicit. |
Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
|
The SC approved the proposed changes. |
|
For reference: python/steering-council#186 (comment) |
…ython#3122) - Lazy evaluation means that referencing a later type variable works at runtime - Disallow walrus in TypeVar bounds, and also disallow yield/yield from/await in the same contexts - Remove rejection of lambda lifting; that is the implementation we are using now - Change the AST - Change of direction on mangling - More precise scoping rules Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com> Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
* Improve PEP 649's description of its semantics. * Stipulate that name resolution for annotations under 649 must be *identical* to stock semantics. * *Don't* specify exactly the mechanism that conformant implementations must use to implement 649. Instead, *do* describe how CPython might do it, but leave the actual details of how to implement 649 up to each language implementation. * Incorporate Jelle's suggestion that the formats for inspect.get_annotations() be in an enum.IntEnum. * Fix lint. * PEP 693: Postpone 3.12.0b1 by two weeks (#3139) * PEP 695: Lazy evaluation, concrete scoping semantics, other changes (#3122) - Lazy evaluation means that referencing a later type variable works at runtime - Disallow walrus in TypeVar bounds, and also disallow yield/yield from/await in the same contexts - Remove rejection of lambda lifting; that is the implementation we are using now - Change the AST - Change of direction on mangling - More precise scoping rules Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com> Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com> * Incorporate changes from feedback, mark Accepted. * Fix PEP 12 header *order compliance*. Wow. * Fix Sphinx complaints. * Make enum consistent, flesh out observed semantics. * Add "Resolution" header, as pointed out by Hugo. * Switch to other URL for Resolution header. * Apply ``global_enum`` to ``inspect.AnnotationFormat`` * Final? text / semantics cleanup pass. * "accept" -> "accepts". Bettering my Englishes. * Add new "post history" reflecting the updates. * Update post history with all conversations, courtesy CAM! Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM> * Fix typo. Thanks, Emily! Co-authored-by: Emily Morehouse <emilyemorehouse@gmail.com> * Add "Discussions-To" header. Thanks, CAM! Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM> * Attempt to satisfy "validate-post-history" hook. --------- Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com> Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com> Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com> Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com> Co-authored-by: Adam Turner <9087854+aa-turner@users.noreply.github.com> Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM> Co-authored-by: Emily Morehouse <emilyemorehouse@gmail.com>
This adds some clarifications and changes that I ran into while implementing the PEP.
The most important change is that TypeVar bounds and type alias values are lazily evaluated using PEP 649-like semantics. This will make the language more consistent once type annotations are evaluated using PEP 649.
Prior discussion:
__type_params__attribute replacing__type_variables__: Semantics of__type_variables__erictraut/cpython#10, Clarification in the choice of __type_variables__ vs __type_param(eter)?s__ erictraut/cpython#8yieldetc.: Prohibit yield, yield from, await, walrus in aliases and bounds? erictraut/cpython#13I am marking this as draft for now in case I run into more things that need to be changed. We'll have to ask the SC for approval, but hopefully these changes are not controversial.
cc @erictraut
📚 Documentation preview 📚: https://pep-previews--3122.org.readthedocs.build/