GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — PEP 695: Lazy evaluation, concrete scoping semantics, other changes by JelleZijlstra · Pull Request #3122 · python/peps

Conversation

@JelleZijlstra

@JelleZijlstra JelleZijlstra commented Apr 24, 2023 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Member

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:

  • PEP 649-like semantics: Lazy evaluation and PEP 649 erictraut/cpython#11
  • __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#8
  • Disallowing yield etc.: Prohibit yield, yield from, await, walrus in aliases and bounds? erictraut/cpython#13

I 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/

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@JelleZijlstra
PEP 695: Changes proposed as a result of implementation work
5b3bbee
erictraut
erictraut approved these changes Apr 24, 2023
View reviewed changes

@erictraut erictraut left a comment

Copy link
Copy Markdown
Contributor

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
gvanrossum
gvanrossum reviewed Apr 24, 2023
View reviewed changes

@gvanrossum gvanrossum left a comment

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some preliminary comments while I have this freshly in my head.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

JelleZijlstra added 3 commits April 24, 2023 18:09
@JelleZijlstra
It does not all have to be C
23a6c4d
@JelleZijlstra
If PEP 649 is accepted, we should support formats
a20d27c
@JelleZijlstra
Two more updates:
bb3c770
- 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
@JelleZijlstra JelleZijlstra mentioned this pull request Apr 25, 2023
gh-103763: Implement PEP 695 python/cpython#103764
Merged
@JelleZijlstra
Remove rejection of lambda lifting; that is the implementation we are…
af90161
… using now
JelleZijlstra
JelleZijlstra commented Apr 25, 2023
View reviewed changes
Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

@JelleZijlstra

JelleZijlstra commented Apr 25, 2023

Copy link
Copy Markdown
Member Author

@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.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

erictraut
erictraut reviewed Apr 25, 2023
View reviewed changes
Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

@JelleZijlstra
Longer discussion of lazy eval
8b43966
JelleZijlstra
JelleZijlstra commented Apr 26, 2023
View reviewed changes
Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

@JelleZijlstra
Update pep-0695.rst
6d80750
@JelleZijlstra JelleZijlstra changed the title PEP 695: Changes proposed as a result of implementation work PEP 695: Lazy evaluation and other small changes Apr 26, 2023
@JelleZijlstra
Merge branch 'main' into pep695change
3037e47
@JelleZijlstra
JelleZijlstra marked this pull request as ready for review April 26, 2023 16:27
@JelleZijlstra JelleZijlstra added the DO-NOT-MERGE label Apr 26, 2023
@JelleZijlstra

JelleZijlstra commented Apr 26, 2023

Copy link
Copy Markdown
Member Author

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

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

AlexWaygood
AlexWaygood reviewed Apr 26, 2023
View reviewed changes
Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

JelleZijlstra added 3 commits April 26, 2023 11:37
@JelleZijlstra
Some comments from Alex
e9969bd
@JelleZijlstra
Rewording
868bf7d
@JelleZijlstra
Another Alex suggestion
a009ae4
gvanrossum
gvanrossum approved these changes Apr 26, 2023
View reviewed changes

@gvanrossum gvanrossum left a comment

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for 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.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

@cdce8p

cdce8p commented Apr 26, 2023

Copy link
Copy Markdown
Contributor

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

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

peps/pep-0695.rst

Line 802 in 63a594f

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

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

JelleZijlstra added 2 commits April 26, 2023 15:18
@JelleZijlstra
Change the AST
608dedf
@JelleZijlstra
Change of direction on mangling
a064f11
@JelleZijlstra

JelleZijlstra commented Apr 27, 2023

Copy link
Copy Markdown
Member Author

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

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

gvanrossum
gvanrossum approved these changes Apr 27, 2023
View reviewed changes

@gvanrossum gvanrossum left a comment

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for 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.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@erictraut

erictraut commented Apr 27, 2023

Copy link
Copy Markdown
Contributor

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?
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@JelleZijlstra

JelleZijlstra commented Apr 27, 2023

Copy link
Copy Markdown
Member Author

@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,)}
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

JelleZijlstra added 2 commits May 2, 2023 15:12
@JelleZijlstra
Merge branch 'main' into pep695change
7996ecc
@JelleZijlstra
More precise scoping rules
f446963
@JelleZijlstra JelleZijlstra changed the title PEP 695: Lazy evaluation and other small changes PEP 695: Lazy evaluation, concrete scoping semantics, other changes May 4, 2023
AlexWaygood
AlexWaygood reviewed May 4, 2023
View reviewed changes
Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

@JelleZijlstra @AlexWaygood
Update pep-0695.rst
368cc48
Co-authored-by: Alex Waygood <[email protected]>
JelleZijlstra
JelleZijlstra commented May 4, 2023
View reviewed changes
Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

JelleZijlstra added 2 commits May 4, 2023 08:33
@JelleZijlstra
Update pep-0695.rst
607373c
@JelleZijlstra
Update pep-0695.rst
90101e1
markshannon
markshannon reviewed May 4, 2023
View reviewed changes

@markshannon markshannon left a comment

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for 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.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

@JelleZijlstra

JelleZijlstra commented May 4, 2023

Copy link
Copy Markdown
Member Author

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.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

JelleZijlstra added 2 commits May 4, 2023 08:53
@JelleZijlstra
Clarify where def695 scopes are used
62d4d50
@JelleZijlstra
GitHub downtime made me write more
0e5160f
hauntsaninja
hauntsaninja reviewed May 5, 2023
View reviewed changes
Comment thread pep-0695.rst Resolved

Uh oh!

There was an error while loading. Please reload this page.

@AlexWaygood @hauntsaninja
fix pep number typo
1654a1b
Co-authored-by: Shantanu <[email protected]>
@JelleZijlstra

JelleZijlstra commented May 8, 2023

Copy link
Copy Markdown
Member Author

The SC approved the proposed changes.

erictraut and hugovk reacted with thumbs up emoji
All reactions
  • 👍 2 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@JelleZijlstra
JelleZijlstra merged commit 5cea9b5 into python:main May 8, 2023
@JelleZijlstra
JelleZijlstra deleted the pep695change branch May 8, 2023 18:21
@hugovk

hugovk commented May 8, 2023

Copy link
Copy Markdown
Member

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

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

larryhastings pushed a commit to larryhastings/peps that referenced this pull request May 8, 2023
@JelleZijlstra @AlexWaygood
@hauntsaninja @larryhastings
PEP 695: Lazy evaluation, concrete scoping semantics, other changes (p…
108f275
…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]>
larryhastings added a commit that referenced this pull request May 16, 2023
@larryhastings @hugovk
@JelleZijlstra @AlexWaygood @hauntsaninja @AA-Turner @CAM-Gerlach @emilyemorehouse
PEP 649: Improve description of semantics and mark as accepted (#3138)
a111ec4
* 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]>
@coderabbitai coderabbitai Bot mentioned this pull request Aug 19, 2026
fix(meaningless-vars): complete scope-aware rename planning alessio-locatelli/ruff-extra-rules#186
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@carljm carljm carljm left review comments
@markshannon markshannon markshannon left review comments
@hauntsaninja hauntsaninja hauntsaninja left review comments
@AlexWaygood AlexWaygood AlexWaygood left review comments
@gvanrossum gvanrossum gvanrossum approved these changes
+1 more reviewer
@erictraut erictraut erictraut approved these changes
Reviewers whose approvals may not affect merge requirements

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

DO-NOT-MERGE

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

9 participants

@JelleZijlstra @cdce8p @erictraut @hugovk @carljm @gvanrossum @markshannon @hauntsaninja @AlexWaygood
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.