@@ -109,7 +109,7 @@ This is expected to be a common pattern, so we cannot afford to break such code
109
109
the upgrade from 3.13 to 3.14.
110
110
111
111
Such code would still break when the future import is eventually removed. However, this
112
- is many years in the future, giving affected decorators plenty of time to update their code.
112
+ is many years in the future, giving affected libraries plenty of time to update their code.
113
113
114
114
*Immediately deprecate the future import *: Instead of waiting until Python 3.13 reaches
115
115
its end-of-life, we could immediately start emitting warnings when the future import is
@@ -185,10 +185,9 @@ Specification
185
185
A new module, ``annotationlib ``, is added to the standard library. Its aim is to
186
186
provide tooling for introspecting and wrapping annotations.
187
187
188
- The exact contents of the module are not yet specified. We will add support for
189
- :pep: `649 ` semantics to standard library functionality that uses annotations, such
190
- as :py:mod: `dataclasses ` and :py:class: `typing.TypedDict `, and use the experience
191
- to inform the design of the new module.
188
+ The design of the module is informed by the experience of updating the standard
189
+ library (e.g., :py:mod: `dataclasses ` and :py:class: `typing.TypedDict `) to use
190
+ :pep: `649 ` semantics.
192
191
193
192
The module will contain the following functionality:
194
193
@@ -251,10 +250,10 @@ Contrary to :pep:`649`, the annotation formats (``VALUE``, ``FORWARDREF``, and `
251
250
will not be added as global members of the :py:mod: `inspect ` module. The only recommended
252
251
way to refer to these constants will be as ``annotationlib.Format.VALUE ``.
253
252
254
- Open issues
255
- -----------
253
+ Rejected alternatives
254
+ ---------------------
256
255
257
- What should this module be called? Some ideas:
256
+ * Use a different name *: Naming is hard, and I considered several ideas:
258
257
259
258
- ``annotations ``: The most obvious name, but it may cause confusion with the existing
260
259
``from __future__ import annotations ``, because users may have both ``import annotations ``
@@ -276,8 +275,7 @@ What should this module be called? Some ideas:
276
275
- ``annotationlib ``: Similar to the above, but one character shorter and subjectively reads
277
276
better. Also not taken on PyPI.
278
277
279
- Rejected alternatives
280
- ---------------------
278
+ ``annotationlib `` appears to be the best option.
281
279
282
280
*Add the functionality to the inspect module *: As described above, the
283
281
:py:mod: `inspect ` module is already quite large, and its import time is prohibitive
@@ -802,15 +800,10 @@ Signature of ``__annotate__`` functions
802
800
``__annotate__(format: int) -> dict ``
803
801
804
802
However, using ``format `` as a parameter name could lead to collisions
805
- if an annotation uses a symbol named ``format ``. The parameter should be
806
- positional-only and have a name that cannot be a legal identifier in order
807
- to avoid this problem.
808
-
809
- The current implementation uses the name ``.format `` with a leading
810
- dot, but the exact name should be considered an implementation detail
811
- and cannot be relied upon.
812
-
813
- The documentation may still use the name ``format `` for simplicity.
803
+ if an annotation uses a symbol named ``format ``. To avoid this problem,
804
+ the current implementation uses a positional-only parameter that is named
805
+ ``format `` in the function signature, but that does not shadow use of the name
806
+ ``format `` within the annotation.
814
807
815
808
Backwards Compatibility
816
809
=======================
@@ -874,17 +867,8 @@ who need to interact programmatically with annotations.
874
867
Reference Implementation
875
868
========================
876
869
877
- The in-progress PR `#119891 <https://github.com/python/cpython/pull/119891 >`__
878
- implements much of this PEP.
879
-
880
- Open Issues
881
- ===========
882
-
883
- We may discover additional areas where :pep: `649 ` needs clarification or amendment
884
- as we make progress on implementing it. Readers are encouraged to follow the
885
- `CPython issue <https://github.com/python/cpython/issues/119180 >`__ tracking the
886
- implementation of the PEP and try out the draft implementation. Any feedback may
887
- be incorporated into future versions of this PEP.
870
+ The changes proposed in this PEP have been implemented on the main branch
871
+ of the CPython repository.
888
872
889
873
Acknowledgments
890
874
===============
@@ -895,7 +879,8 @@ initial decisions, but the overall design is still his.
895
879
I thank Carl Meyer and Alex Waygood for feedback on early drafts of this PEP. Alex Waygood,
896
880
Alyssa Coghlan, and David Ellis provided insightful feedback and suggestions on the
897
881
interaction between metaclasses and ``__annotations__ ``. Larry Hastings also provided useful
898
- feedback on this PEP.
882
+ feedback on this PEP. Nikita Sobolev made various changes to the standard library that make
883
+ use of PEP 649 functionality, and his experience helped improve the design.
899
884
900
885
Appendix
901
886
========
0 commit comments