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

PEP 729: A few proposed small changes (#3483) 

* Remove a "now", which gets repeated in the next sentence.
* Add explanations behind PEP numbers.
* Move "conformance tests" behind "buy-in" items, seems it seems to me that buy-in should come before writing the tests.
This commit is contained in:
Sebastian Rittau 2023-10-13 15:51:44 +02:00 committed by GitHub
parent b9138054bc
commit 4ea40e0d6a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
peps/pep-0729.rst
View File

@ -20,7 +20,7 @@ specification and conformance test suite and will initially be appointed by the
Motivation
==========
The Python type system was created by :pep:`484`, now almost ten years ago. The type
The Python type system was created by :pep:`484`, almost ten years ago. The type
system is now widely used, and typing has become an important tool for writing
good, maintainable Python code. Many changes have been made to the type system to cover
more use cases and improve usability. Several type checkers have been created, each
@ -207,15 +207,17 @@ Some examples of how past and recent issues could have been handled under this m
- A PEP like :pep:`695` (type parameter syntax), which changes the language
syntax, would need to be decided upon by the Steering Council; the Typing
Council would merely provide opinion or endorsement. Similarly, PEPs
like :pep:`702` would be decided upon by the Steering
like :pep:`702` (deprecations) would be decided upon by the Steering
Council, because it concerns runtime behaviour beyond pure typing. Other examples
that would need to be decided by the SC include :pep:`718` and :pep:`727`.
that would need to be decided by the SC include :pep:`718` (subscriptable
functions) and :pep:`727` (documentation metadata).
- A PEP like :pep:`698` (``@override``), which affects only users of type
checkers and does not change the overall language, would also by default
be decided upon by the Steering Council. However, such PEPs could be
delegated to the Typing Council for a decision (like any other PEP delegation).
Other examples of PEPs that could potentially be delegated include
:pep:`647`, :pep:`655`, :pep:`673`, and :pep:`675`.
:pep:`647` (type guards), :pep:`655` (individual required ``TypedDict`` items),
:pep:`673` (``Self``), and :pep:`675` (``Literal``).
- Adding a smaller feature, such as :data:`typing.Never` as an alias for
:data:`typing.NoReturn`, would be done by means of a PR to the spec and
conformance test suite. The Typing
@ -318,8 +320,6 @@ as a means to achieve a better formalisation of the spec.
Proposed changes to the specification, including PEPs, should
generally be accompanied by the following:
* Changes to the conformance test suite that demonstrate the
specified behavior.
* Buy-in from type checker maintainers to confirm that the
change can be implemented and maintained within their type
checkers.
@ -327,6 +327,8 @@ generally be accompanied by the following:
of existing type checkers. If existing type checkers
behave roughly similarly, that is evidence that their shared
behavior should be made part of the specification.
* Changes to the conformance test suite that demonstrate the
specified behavior.
User-facing reference for the type system
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^