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

PEP 8013: Completed first draft (#778)

This commit is contained in:
Steve Dower 2018-09-15 19:59:21 -07:00 committed by GitHub
parent 5138fd0336
commit 1fda80f6ad
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 123 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

156
pep-8013.rst
View File

@ -38,7 +38,8 @@ Some suggestions in this document are currently weak suggestions, and
are open to change during the discussion period. These include: are open to change during the discussion period. These include:
* We can change the name of the group. "Council of Auditors" is the * We can change the name of the group. "Council of Auditors" is the
suggested alternative. suggested alternative, though "Python Inquisition" is very tempting
if we believe we can be clear about the source of the name [1]_
* We can change voting procedures, timelines, and tie-breakage rules * We can change voting procedures, timelines, and tie-breakage rules
@ -75,11 +76,13 @@ Key people and their functions
The Group of Unbiased Independent Directors of Order (GUIDO) is a The Group of Unbiased Independent Directors of Order (GUIDO) is a
council of varying size, typically two to four people, who are elected council of varying size, typically two to four people, who are elected
for the duration of a Python release. GUIDO has responsibility for for the duration of a Python release. One member of GUIDO is
reviewing controversial decisions in the form of PEPs written by considered the President, who has some minor points of authority over
members of the core development team. the other members.
GUIDO may choose to accept a PEP exactly as presented, or may request GUIDO has responsibility for reviewing controversial decisions in the
form of PEPs written by members of the core development team. GUIDO
may choose to accept a PEP exactly as presented, or may request
clarification or changes. These changes may be of any form and for any clarification or changes. These changes may be of any form and for any
reason. This flexibility is intentional, and allows the process to reason. This flexibility is intentional, and allows the process to
change over time as different members are elected to GUIDO. See the change over time as different members are elected to GUIDO. See the
@ -90,24 +93,35 @@ GUIDO only pronounces on PEPs submitted to python-committers. There is
no expectation that GUIDO follows or participates on any other mailing no expectation that GUIDO follows or participates on any other mailing
lists. lists.
The Release Manager (RM) is also permitted the same ability to accept GUIDO may not delegate authority to individuals who have not been
or request changes on any PEPs that specify the release they are elected by the core developer team. (One relevant case here is that
responsible for. After feature freeze, the RM retains this this changes the implementation of the existing BDFL-Delegate system,
responsibility for their release, while GUIDO rotates and begins to though without necessarily changing the spirit of that system. See the
focus on the subsequent release. This is no different from the current later sections for more discussion on this point.)
process. The process for selection of a RM is not changed in this
proposal. The Release Manager (RM) is also permitted the same ability to request
changes on any PEPs that specify the release they are responsible for.
After feature freeze, the RM retains this responsibility for their
release, while GUIDO rotates and begins to focus on the subsequent
release. This is no different from the current process. The process
for selection of a RM is not changed in this proposal.
Core developers are responsible for electing members of GUIDO, and Core developers are responsible for electing members of GUIDO, and
have the ability to call a "vote of no confidence" in members of have the ability to call a "vote of no confidence" against a member of
GUIDO. The details of these votes are discussed below. GUIDO. The details of these votes are discussed in a later section.
Where discussions between core developers and members of GUIDO appear
to be ongoing but unfruitful, the President may step in to overrule
either party. Where the discussion involves the President, it should
be handled using a vote of no confidence.
Members of GUIDO may choose to resign at any point. If at least two Members of GUIDO may choose to resign at any point. If at least two
members of GUIDO remain, they may request a new election to refill the members of GUIDO remain, they may request a new election to refill the
group. If only one member remains, the election is triggered group. If only one member remains, the election is triggered
automatically. automatically. (The scenario when the President resigns is described
in a later section.)
The intended balance of power is that the core developers elect The intended balance of power is that the core developers will elect
members of GUIDO who reflect the direction and have the trust of the members of GUIDO who reflect the direction and have the trust of the
development team, and also have the ability to remove members who do development team, and also have the ability to remove members who do
not honour commitments made prior to election. not honour commitments made prior to election.
@ -117,31 +131,35 @@ Regular decision process
Regular decisions continue to be made as at present. Regular decisions continue to be made as at present.
For the sake of clarity, decisions requiring a PEP are always treated For the sake of clarity, controversial decisions require a PEP, and
as controversial. any decisions requiring a PEP are considered as controversial.
GUIDO may be asked to advise on whether a decision would be better GUIDO may be asked to advise on whether a decision would be better
made using the controversial decision process, but the core made using the controversial decision process, or individual members
development team is not bound by such advice. of GUIDO may volunteer such a suggestion, but the core development
team is not bound by this advice.
Controversial decision process Controversial decision process
------------------------------ ------------------------------
Controversial decisions are always written up as PEPs, following the Controversial decisions are always written up as PEPs, following the
existing process. The approver (formerly "BDFL-Delegate") is always existing process. The approver (formerly "BDFL-Delegate") is always
GUIDO. GUIDO, and can no longer be delegated. Note that this does not
prevent GUIDO from deciding to nominate a core developer to assess the
proposal and provide GUIDO with a recommendation, which is essentially
the same as the current delegation process.
GUIDO will pronounce on PEPs submitted to python-committers with a GUIDO will pronounce on PEPs submitted to python-committers with a
request for pronouncement. Any member of GUIDO may request changes to request for pronouncement. Any member of GUIDO, or the current RM, may
a PEP for any reason, provided they include some indication of what request changes to a PEP for any reason, provided they include some
additional work is required to meet their expectations. See later indication of what additional work is required to meet their
sections for examples of expected reasons. expectations. See later sections for examples of expected reasons.
When all members of GUIDO indicate that they have no concerns with a When all members of GUIDO and the RM indicate that they have no
PEP, it is formally accepted. When one or more members of GUIDO fail concerns with a PEP, it is formally accepted. When one or more members
to respond in a reasonable time, the President of GUIDO may choose to of GUIDO fail to respond in a reasonable time, the President of GUIDO
interpret that as implied approval. Failure of the President to may choose to interpret that as implied approval. Failure of the
respond should be handled using a vote of no confidence. President to respond should be handled using a vote of no confidence.
Election terms Election terms
-------------- --------------
@ -219,18 +237,90 @@ should allocate votes on this basis.
Scenario 1 - The Case of the Vague PEP Scenario 1 - The Case of the Vague PEP
-------------------------------------- --------------------------------------
TODO Often in the past, initial proposals have lacked sufficient detail to
be implementable by anyone other than the proposer. To avoid this,
GUIDO should read proposals "fresh" when submitted, and without
inferring or using any implied context. Then, when an aspect of a PEP
is not clear, GUIDO can reject the proposal and request
clarifications.
Since the proposal is rejected, it must be modified and resubmitted in
order to be reviewed again. GUIDO will determine how much guidance to
provide when rejecting the PEP, as that will affect how many times it
will likely be resubmitted (and hence affect GUIDO's own workload).
This ensures that the final PEP text stands alone with all required
information.
Scenario 2 - The Case of the Endless Discussion Scenario 2 - The Case of the Endless Discussion
----------------------------------------------- -----------------------------------------------
TODO From time to time, a discussion between Python contributors may seem
to be no longer providing value. For example, when a large number of
emails are repeating points that have already been dealt with, or are
actively hostile towards others, there is no point continuing the
"discussion".
When such a discussion is occurring on python-committers as part of a
request for pronouncement, a member of GUIDO should simply declare the
thread over by rejecting the proposal. In most known cases, discussion
of this sort indicates that not all concerns have been sufficiently
addressed in the proposal and the author may need to enhance some
sections.
Alternatively, and in the absence of any rejection from the other
members of GUIDO, the President may declare the thread over by
accepting the proposal. Ideally this would occur after directly
confirming with the rest of GUIDO and the RM that there are no
concerns among them.
When such a discussion is occurring on another list, members of GUIDO
should be viewed as respected voices similar to other core developers
(particularly those core developers who are the named experts for the
subject area). While none have specific authority to end a thread,
preemptively stating an intent to block a proposal is a useful way to
defuse potentially useless discussions. Members of GUIDO who
voluntarily follow discussions other than on python-committers are
allowed to suggest the proposer withdraw, but can only actually
approve or reject a proposal that is formally submitted for
pronouncement.
Scenario 3 - The Case of the Unconsidered Users Scenario 3 - The Case of the Unconsidered Users
----------------------------------------------- -----------------------------------------------
TODO Some proposals in the past may be written up and submitted for
pronouncement without considering the impact on particular groups of
users. For example, a proposal that affects the dependencies required
to use Python on various machines may have an adverse impact on some
users, even if many are unaffected due to the dependencies being
typically available by default.
Where a proposal does not appear to consider all users, GUIDO might
choose to use their judgement and past experience to determine that
more users are affected by the change than described in the PEP, and
request that the PEP also address these users. They should identify
the group of users clearly enough that the proposer is able to also
identify these users, and either clarify how they were addressed, or
made amendments to the PEP to explicitly address them. (Note that this
does not involve evaluating the usefulness of the feature to various
user groups, but simply whether the PEP indicates that the usefulness
of the feature has been evaluated.)
Where a proposal appears to have used flawed logic or incorrect data
to come to a certain conclusion, GUIDO might choose to use other
sources of information (such as the prior discussion or a submission
from other core developers) to request reconsideration of certain
points. The proposer does not necessarily need to use the exact
information obtained by GUIDO to update their proposal, provided that
whatever amendments they make are satisfactory to GUIDO. For example,
a PEP may indicate that 30% of users would be affected, while GUIDO
may argue that 70% of users are affected. A successful amendment may
include a different but more reliable percentage, or may be rewritten
to no longer depend on the number of affected users.
References
==========
.. [1] The Spanish Inquisition, `<https://youtu.be/Ixgc_FGam3s>`_
Copyright Copyright
========= =========