iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fixes to PEP 649 based on feedback. (#3124) 

* Move the "Mistaken rejection" section up to Overview.
* Stipulate that the exact value of strings returned by SOURCE
  format may change in the future.
* Disallow walrus and generator operators in annotation expressions.
This commit is contained in:
larryhastings 2023-04-25 15:14:54 -07:00 committed by GitHub
parent 70532f8abf
commit b49ab691d8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 51 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

84
pep-0649.rst
View File

@ -219,6 +219,37 @@ has the correct value--the class ``MyType``--even though
defined.
Mistaken Rejection Of This Approach In November 2017
====================================================
During the early days of discussion around :pep:`563`,
in a November 2017 thread in ``comp.lang.python-dev``,
the idea of using code to delay the evaluation of
annotations was briefly discussed. At the time the
technique was termed an "implicit lambda expression".
Guido van Rossum—Python's BDFL at the time—replied,
asserting that these "implicit lambda expression" wouldn't
work, because they'd only be able to resolve symbols at
module-level scope:
IMO the inability of referencing class-level definitions
from annotations on methods pretty much kills this idea.
https://mail.python.org/pipermail/python-dev/2017-November/150109.html
This led to a short discussion about extending lambda-ized
annotations for methods to be able to refer to class-level
definitions, by maintaining a reference to the class-level
scope. This idea, too, was quickly rejected.
:pep:`PEP 563 summarizes the above discussion
<563#keeping-the-ability-to-use-function-local-state-when-defining-annotations>`
The approach taken by this PEP doesn't suffer from these
restrictions. Annotations can access module-level definitions,
class-level definitions, and even local and free variables.
**********
Motivation
@ -491,37 +522,6 @@ approach to solve the problems facing annotations users,
resulting in this PEP.
Mistaken Rejection Of This Approach In November 2017
====================================================
During the early days of discussion around :pep:`563`,
in a November 2017 thread in ``comp.lang.python-dev``,
the idea of using code to delay the evaluation of
annotations was briefly discussed. At the time the
technique was termed an "implicit lambda expression".
Guido van Rossum—Python's BDFL at the time—replied,
asserting that these "implicit lambda expression" wouldn't
work, because they'd only be able to resolve symbols at
module-level scope:
IMO the inability of referencing class-level definitions
from annotations on methods pretty much kills this idea.
https://mail.python.org/pipermail/python-dev/2017-November/150109.html
This led to a short discussion about extending lambda-ized
annotations for methods to be able to refer to class-level
definitions, by maintaining a reference to the class-level
scope. This idea, too, was quickly rejected.
:pep:`PEP 563 summarizes the above discussion
<563#keeping-the-ability-to-use-function-local-state-when-defining-annotations>`
The approach taken by this PEP doesn't suffer from these
restrictions. Annotations can access module-level definitions,
class-level definitions, and even local and free variables.
.. _Implementation:
**************
@ -580,9 +580,10 @@ Language Reference:
``2`` (exported as ``inspect.SOURCE``)
Values are the text string of the annotation as it
appears in the source code. May only be approximate;
appears in the source code. May only be approximate;
whitespace may be normalized, and constant values may
be optimized.
be optimized. It's possible the exact values of these
strings could change in future version of Python.
``3`` (exported as ``inspect.FORWARDREF``)
@ -680,7 +681,24 @@ an object of any of these three types:
creates, caches, and returns a new empty dict. (This is for
backwards compatibility with :pep:`3107` semantics.)
Changes to allowable annotations syntax
=======================================
``__annotate__`` now delays the evaluation of annotations until
``__annotations__`` is referenced in the future. It also means
annotations are evaluated in a new function, rather than in the
original context where the object they were defined on was bound.
There are four operators with significant runtime side-effects
that were permitted in stock semantics, but are disallowed when
``from __future__ import annotations`` is active, and will have
to be disallowed when this PEP is active:
```
:=
yield
yield from
await
```
Changes to ``inspect.get_annotations`` and ``typing.get_type_hints``
====================================================================