Skip to content

PEP 695: Lazy evaluation, concrete scoping semantics, other changes #3122

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
JelleZijlstra merged 21 commits into from
May 8, 2023
Merged

PEP 695: Lazy evaluation, concrete scoping semantics, other changes #3122

Changes from 1 commit
Commits
Show all changes
21 commits
Select commit Hold shift + click to select a range
5b3bbee
PEP 695: Changes proposed as a result of implementation work
JelleZijlstra Apr 24, 2023
23a6c4d
It does not all have to be C
JelleZijlstra Apr 25, 2023
a20d27c
If PEP 649 is accepted, we should support formats
JelleZijlstra Apr 25, 2023
bb3c770
Two more updates:
JelleZijlstra Apr 25, 2023
af90161
Remove rejection of lambda lifting; that is the implementation we are…
JelleZijlstra Apr 25, 2023
8b43966
Longer discussion of lazy eval
JelleZijlstra Apr 25, 2023
6d80750
Update pep-0695.rst
JelleZijlstra Apr 26, 2023
3037e47
Merge branch 'main' into pep695change
JelleZijlstra Apr 26, 2023
e9969bd
Some comments from Alex
JelleZijlstra Apr 26, 2023
868bf7d
Rewording
JelleZijlstra Apr 26, 2023
a009ae4
Another Alex suggestion
JelleZijlstra Apr 26, 2023
608dedf
Change the AST
JelleZijlstra Apr 26, 2023
a064f11
Change of direction on mangling
JelleZijlstra Apr 27, 2023
7996ecc
Merge branch 'main' into pep695change
JelleZijlstra May 2, 2023
f446963
More precise scoping rules
JelleZijlstra May 4, 2023
368cc48
Update pep-0695.rst
JelleZijlstra May 4, 2023
607373c
Update pep-0695.rst
JelleZijlstra May 4, 2023
90101e1
Update pep-0695.rst
JelleZijlstra May 4, 2023
62d4d50
Clarify where def695 scopes are used
JelleZijlstra May 4, 2023
0e5160f
GitHub downtime made me write more
JelleZijlstra May 4, 2023
1654a1b
fix pep number typo
AlexWaygood May 5, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Two more updates: 
- 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
  • Loading branch information
@JelleZijlstra
JelleZijlstra committed Apr 25, 2023
commit bb3c770fbc797081aab9f43e833c885091a4a3de
21 changes: 11 additions & 10 deletions pep-0695.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -401,9 +401,9 @@ includes the type parameters. Type parameters can be accessed by name
within inner scopes. As with other symbols in Python, an inner scope can
define its own symbol that overrides an outer-scope symbol of the same name.

Type parameters declared earlier in a type parameter list are visible to
type parameters declared later in the list. This allows later type parameters
to use earlier type parameters within their definition. While there is currently
Type parameters are visible to other
type parameters declared elsewhere in the list. This allows type parameters
Comment thread
JelleZijlstra marked this conversation as resolved.
Resolved
to use other type parameters within their definition. While there is currently
no use for this capability, it preserves the ability in the future to support
upper bound expressions or type argument defaults that depend on earlier
type parameters.
Expand All @@ -420,11 +420,9 @@ defined in an outer scope.
# eliminate this limitation.
class ClassA[S, T: Sequence[S]]: ...

# The following generates a compiler error or runtime exception because T
# is referenced before it is defined. This occurs even though T is defined
# in the outer scope.
T = 0
class ClassB[S: Sequence[T], T]: ... # Compiler error: T is not defined
# The following generates no compiler error, because the bound for ``S``
Comment thread
JelleZijlstra marked this conversation as resolved.
Resolved
# is lazily evaluated. However, type checkers should generate an error.
class ClassB[S: Sequence[T], T]: ...


A type parameter declared as part of a generic class is valid within the
Expand Down Expand Up @@ -589,11 +587,14 @@ When the new type parameter syntax is used for a generic class, assignment
expressions are not allowed within the argument list for the class definition.
Likewise, with functions that use the new type parameter syntax, assignment
expressions are not allowed within parameter or return type annotations, nor
are they allowed within the expression that defines a type alias.
are they allowed within the expression that defines a type alias, or within
the bounds and constraints of a ``TypeVar``. Similarly, ``yield``, ``yield from``,
and ``await`` expressions are disallowed in these contexts.

This restriction is necessary because expressions evaluated within the
new lexical scope should not introduce symbols within that scope other than
the defined type parameters.
the defined type parameters, and should not affect whether the enclosing function
is a generator or coroutine.

::

Expand Down