GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||
GeezerVison is showing github.com — PEP 695: Lazy evaluation, concrete scoping semantics, other changes by JelleZijlstra · Pull Request #3122 · python/peps Conversation
|
|
@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. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
Submitted python/steering-council#186 to the SC to approve these changes. Marking as "DO-NOT-MERGE" until the SC approves. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking care to explain all these details clearly!
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
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) |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Pushed another change related to name mangling (I realized that the wording in the PEP would require severe complications in the symtable). |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
+1 on the mangling change.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
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? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@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,)} |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Co-authored-by: Alex Waygood <[email protected]>
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Definitely an improvement.
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?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Yes, they have identical semantics. Let me push something to make that explicit. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Co-authored-by: Shantanu <[email protected]>
|
The SC approved the proposed changes. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
For reference: python/steering-council#186 (comment) |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
…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 <[email protected]> Co-authored-by: Shantanu <[email protected]>
* 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 <[email protected]> Co-authored-by: Shantanu <[email protected]> * 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 <[email protected]> * Fix typo. Thanks, Emily! Co-authored-by: Emily Morehouse <[email protected]> * Add "Discussions-To" header. Thanks, CAM! Co-authored-by: C.A.M. Gerlach <[email protected]> * Attempt to satisfy "validate-post-history" hook. --------- Co-authored-by: Hugo van Kemenade <[email protected]> Co-authored-by: Jelle Zijlstra <[email protected]> Co-authored-by: Alex Waygood <[email protected]> Co-authored-by: Shantanu <[email protected]> Co-authored-by: Adam Turner <[email protected]> Co-authored-by: C.A.M. Gerlach <[email protected]> Co-authored-by: Emily Morehouse <[email protected]>
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.