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

PEP 1: Suggest people reach out to important projects to support their PEP's motivation (#1842)

This commit is contained in:
Brett Cannon 2021-03-01 15:50:22 -08:00 committed by GitHub
parent 36c87838bc
commit 7d760822a3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
pep-0001.txt
View File

@ -94,12 +94,12 @@ the currently active Python core team members described in PEP 13 [5]_.
Python's BDFL
-------------
Previous versions of this PEP used the title "BDFL-Delegate" for PEP decision makers. This was
a historical reference to Python's previous governance model, where all design
authority ultimately derived from Guido van Rossum, the original creator of the
Python programming language. By contrast, the Steering Council's design
authority derives from their election by the currently active core developers.
Now, PEP-Delegate is used in place of BDFL-Delegate.
Previous versions of this PEP used the title "BDFL-Delegate" for PEP decision
makers. This was a historical reference to Python's previous governance model,
where all design authority ultimately derived from Guido van Rossum, the
original creator of the Python programming language. By contrast, the Steering
Council's design authority derives from their election by the currently active
core developers. Now, PEP-Delegate is used in place of BDFL-Delegate.
PEP Editors
@ -421,8 +421,10 @@ Each PEP should have the following parts/sections:
3. Motivation -- The motivation is critical for PEPs that want to
change the Python language, library, or ecosystem. It should
clearly explain why the existing language specification is
inadequate to address the problem that the PEP solves. PEP
submissions without sufficient motivation may be rejected outright.
inadequate to address the problem that the PEP solves. This can
include collecting documented support for the PEP from important
projects in the Python ecosystem. PEP submissions without
sufficient motivation may be rejected.
4. Rationale -- The rationale fleshes out the specification by
describing why particular design decisions were made. It should
@ -694,6 +696,11 @@ For each new PEP that comes in an editor does the following:
PEP 8 & PEP 7). Editors may correct problems themselves, but are
not required to do so. (Text format is checked by Travis CI.)
* If a project is portrayed as benefiting from or supporting the PEP, make sure
there is some direct indication from the project included to make the support
clear. This is to avoid a PEP accidentally portraying a project as supporting
a PEP when in fact the support is based on conjecture.
If the PEP isn't ready, an editor will send it back to the author for
revision, with specific instructions. If reST formatting is a
problem, ask the author(s) to use PEP 12 as a template and resubmit.