Python Steering Council

Es gibt mehrere Verweise in diesem PEP auf den "Steering Council" oder "Council". Dies bezieht sich auf die aktuellen Mitglieder des gewählten Steering Council, wie in PEP 13 beschrieben, in ihrer Rolle als endgültige Autorität darüber, ob PEPs angenommen oder abgelehnt werden.

Python Core-Entwickler

Es gibt mehrere Verweise in diesem PEP auf "Core-Entwickler". Dies bezieht sich auf die derzeit aktiven Mitglieder des Python-Core-Teams, wie in PEP 13 beschrieben.

BDFL von Python

Frühere Versionen dieses PEPs verwendeten den Titel "BDFL-Delegate" für PEP-Entscheidungsträger. Dies war ein historischer Verweis auf das frühere Governance-Modell von Python, bei dem die gesamte Design-Autorität letztendlich von Guido van Rossum, dem ursprünglichen Schöpfer der Python-Programmiersprache, abgeleitet wurde. Im Gegensatz dazu leitet sich die Design-Autorität des Steering Council von ihrer Wahl durch die derzeit aktiven Core-Entwickler ab. Anstelle von BDFL-Delegate wird nun PEP-Delegate verwendet.

PEP-Editoren

Die PEP-Editoren sind Einzelpersonen, die für die Verwaltung der administrativen und redaktionellen Aspekte des PEP-Workflows verantwortlich sind (z. B. Zuweisung von PEP-Nummern und Änderung ihres Status). Details finden Sie unter Verantwortlichkeiten und Workflow von PEP-Editoren.

Die PEP-Editorschaft erfolgt auf Einladung der aktuellen Editoren und sie können per Erwähnung von @python/pep-editors auf GitHub kontaktiert werden. Der gesamte PEP-Workflow kann über die Issues und Pull-Requests des GitHub PEP-Repositorys abgewickelt werden.

Beginnen Sie mit einer Idee für Python

Der PEP-Prozess beginnt mit einer neuen Idee für Python. Es wird dringend empfohlen, dass ein einzelnes PEP einen einzelnen Hauptvorschlag oder eine neue Idee enthält; je fokussierter das PEP, desto erfolgreicher ist es in der Regel. Die meisten Verbesserungen und Fehlerbehebungen benötigen kein PEP und können direkt im Python Issue Tracker eingereicht werden. Die PEP-Editoren behalten sich das Recht vor, PEP-Vorschläge abzulehnen, wenn sie zu unfokussiert oder zu breit erscheinen. Im Zweifelsfall teilen Sie Ihr PEP in mehrere gut fokussierte auf.

Jedes PEP muss einen Paten haben – jemanden, der das PEP im unten beschriebenen Stil und Format schreibt, die Diskussionen in den entsprechenden Foren betreut und versucht, einen Community-Konsens um die Idee herum aufzubauen. Der PEP-Pate (auch Autor genannt) sollte zunächst versuchen festzustellen, ob die Idee PEP-fähig ist. Das Posten in der Ideen-Kategorie von Python Discourse ist normalerweise der beste Weg, es sei denn, ein spezialisierteres Forum ist geeignet, wie die Typing-Kategorie (für Ideen zur statischen Typisierung) oder die Packaging-Kategorie (für Verpackungsideen) auf Python Discourse.

Die öffentliche Prüfung einer Idee, bevor sie so weit geht, ein PEP zu schreiben, soll dem potenziellen Autor Zeit sparen. Viele Ideen wurden zur Änderung von Python vorgebracht, die aus verschiedenen Gründen abgelehnt wurden. Das Vorabfragen an die Python-Community, ob eine Idee originell ist, hilft, zu viel Zeit für etwas aufzuwenden, das garantiert abgelehnt wird, basierend auf früheren Diskussionen (die Suche im Internet reicht manchmal nicht aus). Es hilft auch sicherzustellen, dass die Idee für die gesamte Community und nicht nur für den Autor relevant ist. Nur weil eine Idee dem Autor gut erscheint, heißt das nicht, dass sie für die meisten Menschen in den meisten Bereichen, in denen Python verwendet wird, funktioniert.

Sobald der Pate die Python-Community gefragt hat, ob eine Idee eine Chance auf Akzeptanz hat, sollte ein Entwurf für ein PEP im oben genannten geeigneten Forum vorgestellt werden. Dies gibt dem Autor die Möglichkeit, den Entwurf des PEPs zu verfeinern, um ihn richtig formatiert und von hoher Qualität zu machen und um anfängliche Bedenken bezüglich des Vorschlags zu adressieren.

Einreichung eines PEPs

Nach der oben genannten anfänglichen Diskussion variiert der Workflow je nachdem, ob einer der Co-Autoren des PEPs Core-Entwickler sind. Wenn einer oder mehrere der Co-Autoren des PEPs Core-Entwickler sind, sind sie für die Einhaltung des unten beschriebenen Prozesses verantwortlich. Andernfalls (d.h. keiner der Co-Autoren sind Core-Entwickler) müssen die PEP-Autoren einen Sponsor für das PEP finden.

Idealerweise wird ein Core-Entwickler als Sponsor identifiziert, aber auch Nicht-Core-Sponsoren können mit Zustimmung des Steering Council ausgewählt werden. Mitglieder des GitHub "PEP-Editoren"-Teams und Mitglieder des Typing Council (PEP 729) sind vorab als Sponsoren genehmigt. Die Aufgabe des Sponsors ist es, dem PEP-Autor Anleitung zu geben, um ihm bei den logistischen Aspekten des PEP-Prozesses zu helfen (ähnlich wie ein Mentor). Ein Sponsor zu sein, disqualifiziert diese Person nicht davon, später ein Co-Autor oder PEP-Delegate zu werden (aber nicht beides). Der Sponsor eines PEPs wird im Feld "Sponsor:" des Headers eingetragen.

Sobald der Sponsor oder die Core-Entwickler, die das PEP co-autorieren, der Meinung sind, dass das PEP zur Einreichung bereit ist, sollte der Vorschlag als Entwurf PEP über eine GitHub Pull Request eingereicht werden. Der Entwurf muss im PEP-Stil geschrieben sein, wie unten beschrieben, andernfalls schlägt er die Überprüfung sofort fehl (obwohl geringfügige Fehler von den Editoren korrigiert werden können).

Der Standard-PEP-Workflow ist

• Sie, der PEP-Autor, forken Sie das PEP-Repository und erstellen Sie eine Datei namens pep-NNNN.rst, die Ihr neues PEP enthält. NNNN sollte die nächste verfügbare PEP-Nummer sein, die noch nicht von einem veröffentlichten oder in-PR-PEP verwendet wird.
• Im Header-Feld "PEP:" tragen Sie die PEP-Nummer ein, die Ihrer Dateinamen entspricht, als Ihre Entwurf-PEP-Nummer.
• Im Header-Feld "Type:" tragen Sie "Standards Track", "Informational" oder "Process" ein, je nach Anwendbarkeit, und für das Feld "Status:" tragen Sie "Draft" ein. Ausführliche Informationen finden Sie unter PEP-Header-Präambel.
• Aktualisieren Sie .github/CODEOWNERS so, dass alle Co-Autoren oder Sponsoren mit Schreibzugriff auf das PEP-Repository für Ihre neue Datei aufgeführt sind. Dies stellt sicher, dass zukünftige Pull-Requests, die die Datei ändern, ihnen zugewiesen werden.
• Pushen Sie dies in Ihr GitHub-Fork und reichen Sie einen Pull-Request ein.
• Die PEP-Editoren überprüfen Ihren PR auf Struktur, Formatierung und andere Fehler. Für ein reST-formatiertes PEP wird PEP 12 als Vorlage bereitgestellt. Es bietet auch eine vollständige Einführung in die reST-Markup-Sprache, die in PEPs verwendet wird. Zulassungskriterien sind
  • Es ist fundiert und vollständig. Die Ideen müssen technisch sinnvoll sein. Die Editoren berücksichtigen nicht, ob sie wahrscheinlich akzeptiert werden.
  • Der Titel beschreibt den Inhalt korrekt.
  • Die Sprache des PEPs (Rechtschreibung, Grammatik, Satzbau usw.) und der Code-Stil (Beispiele sollten mit PEP 7 & PEP 8 übereinstimmen) sollten korrekt und konform sein. Der PEP-Text wird automatisch auf korrekte reStructuredText-Formatierung überprüft, wenn der Pull-Request eingereicht wird. PEPs mit ungültigem reST-Markup werden nicht genehmigt.

  Editoren sind bei dieser anfänglichen Überprüfung im Allgemeinen recht nachsichtig und erwarten, dass Probleme durch den Überprüfungsprozess korrigiert werden. Hinweis: Die Genehmigung des PEPs ist keine Garantie dafür, dass keine peinlichen Fehler vorhanden sind! Korrektheit liegt in der Verantwortung der Autoren und Gutachter, nicht der Editoren.

  Wenn das PEP nicht zur Genehmigung bereit ist, schickt ein Editor es mit spezifischen Anweisungen zur Überarbeitung an den Autor zurück.

• Nach der Genehmigung weisen sie Ihrem PEP eine Nummer zu.

Nach Abschluss des Überprüfungsprozesses und der Genehmigung durch die PEP-Editoren (beachten Sie, dass dies *nicht* dasselbe ist wie die Annahme Ihres PEPs!) werden sie Ihren Pull-Request auf den Hauptzweig squashen und committen.

Die PEP-Editoren verweigern die Veröffentlichung eines PEPs nicht unangemessen. Gründe für die Verweigerung des PEP-Status sind: Duplizierung von Aufwand, technische Undurchführbarkeit, fehlende ordnungsgemäße Begründung oder keine Berücksichtigung der Abwärtskompatibilität oder Nicht-Übereinstimmung mit der Python-Philosophie. Der Steering Council kann während der Genehmigungsphase konsultiert werden und ist der endgültige Schiedsrichter für die PEP-Fähigkeit eines Entwurfs.

Entwickler mit Schreibzugriff auf das PEP-Repository können PEP-Nummern direkt beanspruchen, indem sie ein neues PEP erstellen und committen. Dabei muss der Entwickler die Aufgaben übernehmen, die normalerweise von den PEP-Editoren erledigt würden (siehe Verantwortlichkeiten und Workflow von PEP-Editoren). Dazu gehört die Sicherstellung, dass die Anfangsversion die erwarteten Standards für die Einreichung eines PEP erfüllt. Alternativ sollten auch Entwickler PEPs über Pull-Requests einreichen. Dabei wird im Allgemeinen erwartet, dass Sie den Prozess selbst abwickeln; wenn Sie Hilfe von PEP-Editoren benötigen, erwähnen Sie @python/pep-editors auf GitHub.

Wenn Aktualisierungen erforderlich sind, kann der PEP-Autor neue Versionen einchecken, wenn er (oder ein kooperierender Entwickler) Schreibzugriff auf das PEP-Repository hat. Die frühzeitige Zuweisung einer PEP-Nummer kann für eine einfache Referenz nützlich sein, insbesondere wenn mehrere Entwurf-PEPs gleichzeitig geprüft werden.

Standards Track PEPs bestehen aus zwei Teilen: einem Design-Dokument und einer Referenzimplementierung. Es wird generell empfohlen, zumindest eine Prototypen-Implementierung gemeinsam mit dem PEP zu entwickeln, da Ideen, die im Prinzip gut klingen, sich manchmal als unpraktisch erweisen, wenn sie dem Test der Implementierung unterzogen werden.

Diskussion eines PEPs

Sobald eine PEP-Nummer zugewiesen wurde und der Entwurf PEP im PEP-Repository eingepflegt ist, sollte ein Diskussions-Thread für das PEP erstellt werden, um einen zentralen Ort für die Diskussion und Überprüfung seines Inhalts zu bieten, und das PEP sollte so aktualisiert werden, dass der Header Discussions-To darauf verweist.

Die PEP-Autoren (oder der Sponsor, falls zutreffend) können jedes vernünftige Forum für die Diskussion auswählen, solange die folgenden Kriterien erfüllt sind

• Das Forum ist für das Thema des PEPs geeignet.
• Der Thread ist öffentlich im Web verfügbar, so dass alle Interessierten teilnehmen können.
• Die Diskussion unterliegt dem Python Community Code of Conduct.
• Ein direkter Link zum aktuellen Diskussions-Thread wird im PEP unter dem Header Discussions-To angegeben.

Der PEPs-Bereich von Python Discourse ist die bevorzugte Wahl für die meisten neuen PEPs, während historisch die Python-Dev-Mailingliste häufig genutzt wurde. Einige spezialisierte Themen haben spezifische Foren, wie die Typing-Kategorie und die Packaging-Kategorie auf Python Discourse für Typing- und Packaging-PEPs. Wenn sich die PEP-Autoren über das beste Forum unsicher sind, können der PEP-Sponsor und die PEP-Editoren sie entsprechend beraten.

Wenn ein PEP einer signifikanten Neufassung oder anderen größeren, substanziellen Änderungen an seiner vorgeschlagenen Spezifikation unterzogen wird, sollte typischerweise ein neuer Thread im gewählten Forum erstellt werden, um zusätzliches Feedback einzuholen. Wenn dies geschieht, muss der Discussions-To-Link aktualisiert und ein neuer Post-History-Eintrag hinzugefügt werden, der auf diesen neuen Thread verweist.

Wenn es nicht als Diskussionsforum gewählt wird, sollte ein kurzer Ankündigungspost im PEPs-Bereich gemacht werden, der mindestens einen Link zum gerenderten PEP und zum Discussions-To-Thread enthält, wenn der Entwurf PEP im Repository committet wird und wenn eine ausreichend große Änderung vorgenommen wird, um einen neuen Thread auszulösen.

PEP-Autoren sind dafür verantwortlich, Community-Feedback zu einem PEP zu sammeln, bevor sie es zur Überprüfung einreichen. Um jedoch langwierige und offene Diskussionen zu vermeiden, sollten Strategien wie das Einholen von privatem oder enger zugeschnittenem Feedback in der frühen Designphase, die Zusammenarbeit mit anderen Community-Mitgliedern mit Expertise im Thema des PEPs und die Auswahl einer entsprechend spezialisierten Diskussion für das Thema des PEPs (falls zutreffend) in Betracht gezogen werden. PEP-Autoren sollten hier ihr Ermessen walten lassen.

Sobald das PEP eine Nummer erhalten und im PEP-Repository eingepflegt wurde, sollten wesentliche Probleme generell im kanonischen öffentlichen Thread diskutiert werden, anstatt in privaten Kanälen, GitHub Pull Request Reviews oder auf irrelevanten Plattformen. Dies stellt sicher, dass jeder folgen und beitragen kann, vermeidet die Fragmentierung der Diskussion und stellt sicher, dass sie als Teil des PEP-Überprüfungsprozesses vollständig berücksichtigt wird. Kommentare, Unterstützung, Bedenken und anderes Feedback zu diesem designierten Thread sind ein kritischer Teil dessen, was der Steering Council oder PEP-Delegate bei der Überprüfung des PEPs berücksichtigt.

PEP-Überprüfung und -Entscheidung

Sobald die Autoren ein PEP fertiggestellt haben, können sie eine Überprüfung auf Stil und Konsistenz durch die PEP-Editoren anfordern. Die inhaltliche Überprüfung und Annahme des PEPs liegt jedoch letztendlich in der Verantwortung des Steering Council, die formal durch die Eröffnung eines Steering Council Issues eingeleitet wird, sobald die Autoren (und der Sponsor, falls vorhanden) der Meinung sind, dass das PEP für die endgültige Überprüfung und Entscheidung bereit ist.

Um den Prozess in ausgewählten Fällen zu beschleunigen (z. B. wenn eine Änderung eindeutig vorteilhaft und zur Annahme bereit ist, das PEP aber noch nicht formell zur Überprüfung eingereicht wurde), kann der Steering Council auch eine PEP-Überprüfung einleiten, indem er zunächst den PEP-Autor(en) benachrichtigt und ihnen die Möglichkeit gibt, Überarbeitungen vorzunehmen.

Die endgültige Autorität für die PEP-Annahme ist der Steering Council. Wenn jedoch ein neues PEP vorgelegt wird, kann jeder Core-Entwickler, der glaubt, über die nötige Erfahrung zu verfügen, um die endgültige Entscheidung über dieses PEP zu treffen, anbieten, als dessen PEP-Delegate zu fungieren, indem er dem Steering Council seine Absicht mitteilt. Wenn der Steering Council sein Angebot annimmt, hat der PEP-Delegate die Befugnis, dieses PEP anzunehmen oder abzulehnen. Für PEPs, die das Python-Typsystem betreffen, gibt das Typing Council (PEP 729) eine Empfehlung an den Steering Council ab. Um eine solche Empfehlung anzufordern, öffnen Sie ein Issue im Typing Council Issue Tracker.

Der Begriff "PEP-Delegate" wird im Steering Council Governance-Modell für den designierten Entscheidungsträger des PEPs verwendet, der im Feld "PEP-Delegate" im Header des PEPs eingetragen ist. Der Begriff "BDFL-Delegate" ist ein veralteter Alias für PEP-Delegate, ein Relikt aus der Zeit, als Python von einem BDFL geführt wurde. Alle älteren Verweise auf "BDFL-Delegate" sollten als gleichbedeutend mit "PEP-Delegate" behandelt werden.

Eine Person, die anbietet, sich als PEP-Delegate zu nominieren, muss die relevanten Autoren und (falls vorhanden) den Sponsor des PEPs benachrichtigen und ihren Antrag an den Steering Council stellen (was über ein neues Issue erfolgen kann). Diejenigen, die diese Verantwortung übernehmen, können jederzeit zusätzlichen Rat vom Steering Council einholen und sind auch verpflichtet, die Ratschläge und Perspektiven anderer Core-Entwickler zu berücksichtigen.

Der Steering Council wird solche Selbstnominierungen in der Regel standardmäßig genehmigen, kann sie aber auch ablehnen. Mögliche Gründe für die Ablehnung einer Selbstnominierung als PEP-Delegate durch den Steering Council sind unter anderem die Wahrnehmung eines potenziellen Interessenkonflikts (z. B. die Arbeit für dieselbe Organisation wie der PEP-Einreicher) oder einfach die Ansicht, dass ein anderer potenzieller PEP-Delegate besser geeignet ist. Wenn Core-Entwickler (oder andere Community-Mitglieder) Bedenken hinsichtlich der Eignung eines PEP-Delegates für ein bestimmtes PEP haben, können sie den Steering Council bitten, die Delegation zu überprüfen.

Wenn sich kein Freiwilliger meldet, wird der Steering Council Core-Entwickler (und potenziell andere Mitglieder der Python-Community) mit relevantem Fachwissen ansprechen, um einen Kandidaten zu identifizieren, der bereit ist, als PEP-Delegate für dieses PEP zu fungieren. Wenn kein geeigneter Kandidat gefunden werden kann, wird das PEP als "Deferred" (zurückgestellt) markiert, bis einer verfügbar ist.

Zuvor ernannte PEP-Delegates können zurücktreten oder vom Council zum Rücktritt aufgefordert werden. In diesem Fall wird ein neuer PEP-Delegate auf dieselbe Weise ernannt wie für ein neues PEP (einschließlich der Rückstellung des PEPs, wenn kein geeigneter Ersatz gefunden werden kann). Sollte ein PEP-Delegate zum Rücktritt aufgefordert werden, hat dies Vorrang vor jeder früheren Annahme oder Ablehnung des PEPs, und es wird wieder in den Status "Draft" versetzt.

Wenn solche stehenden Delegationen eingerichtet werden, wird der Steering Council ausreichende öffentliche Aufzeichnungen führen, damit nachfolgende Councils, die Core-Entwickler und die breitere Python-Community die bestehenden Delegationen, deren Gründe und die Umstände, unter denen sie nicht mehr benötigt werden, verstehen können.

Damit ein PEP angenommen werden kann, muss es bestimmte Mindestkriterien erfüllen. Es muss eine klare und vollständige Beschreibung der vorgeschlagenen Verbesserung sein. Die Verbesserung muss eine Nettobesserung darstellen. Die vorgeschlagene Implementierung, falls zutreffend, muss solide sein und darf den Interpreter nicht übermäßig verkomplizieren. Schließlich muss ein vorgeschlagener Enhancement "pythonisch" sein, um vom Steering Council akzeptiert zu werden. (Allerdings ist "pythonisch" ein unpräziser Begriff; er kann als das definiert werden, was vom Steering Council akzeptiert wird. Diese Logik ist bewusst zirkulär.) Siehe PEP 2 für die Annahmekriterien für Module der Standardbibliothek.

Sofern nicht anders vom Steering Council genehmigt, werden Bekanntmachungen über die PEP-Entscheidung im PEPs-Bereich auf Python Discourse veröffentlicht.

Sobald ein PEP angenommen wurde, muss die Referenzimplementierung abgeschlossen werden. Wenn die Referenzimplementierung abgeschlossen und in das Hauptquellcode-Repository integriert ist, wird der Status auf "Final" geändert.

Um das Sammeln von zusätzlichem Design- und Schnittstellenfeedback zu ermöglichen, bevor eine langfristige Stabilität für ein Sprachfeature oder eine Standardbibliotheks-API zugesagt wird, kann ein PEP auch als "Provisional" (vorläufig) markiert werden. Dies ist kurz für "Provisionally Accepted" (vorläufig angenommen) und bedeutet, dass der Vorschlag zur Aufnahme in die Referenzimplementierung angenommen wurde, aber zusätzliches Benutzerfeedback benötigt wird, bevor das vollständige Design als "Final" betrachtet werden kann. Im Gegensatz zu regulären angenommenen PEPs können vorläufig angenommene PEPs noch abgelehnt oder zurückgezogen werden, *auch nachdem die zugehörigen Änderungen in eine Python-Version aufgenommen wurden*.

Wo immer möglich, wird es als vorzuziehen angesehen, den Umfang eines Vorschlags zu reduzieren, um die Notwendigkeit der Nutzung des "Provisional"-Status zu vermeiden (z. B. durch Verschiebung einiger Features auf spätere PEPs), da dieser Status zu Problemen mit der Versionskompatibilität im breiteren Python-Ökosystem führen kann. PEP 411 enthält weitere Details zu potenziellen Anwendungsfällen für den Provisional-Status.

Ein PEP kann auch den Status "Deferred" (zurückgestellt) erhalten. Der PEP-Autor oder ein Editor kann dem PEP diesen Status zuweisen, wenn keine Fortschritte bei dem PEP erzielt werden. Sobald ein PEP zurückgestellt ist, kann ein PEP-Editor es wieder in den Entwurfsstatus versetzen.

Ein PEP kann auch "Rejected" (abgelehnt) werden. Vielleicht war es doch keine gute Idee. Es ist dennoch wichtig, die Aufzeichnung darüber zu führen. Der Status "Withdrawn" (zurückgezogen) ist ähnlich – er bedeutet, dass der PEP-Autor selbst entschieden hat, dass das PEP tatsächlich eine schlechte Idee ist oder dass ein konkurrierender Vorschlag eine bessere Alternative ist.

Wenn ein PEP angenommen, abgelehnt oder zurückgezogen wird, sollte das PEP entsprechend aktualisiert werden. Zusätzlich zur Aktualisierung des Statusfeldes sollte mindestens der Header "Resolution" mit einem direkten Link zum relevanten Beitrag hinzugefügt werden, der eine Entscheidung über das PEP trifft.

PEPs können auch durch ein anderes PEP ersetzt werden, was das Original obsolet macht. Dies ist für Informationelle PEPs vorgesehen, bei denen Version 2 einer API Version 1 ersetzen kann.

Die möglichen Pfade des Status von PEPs sind wie folgt

Obwohl im Diagramm nicht gezeigt, können "Accepted" PEPs technisch zu "Rejected" oder "Withdrawn" übergehen, auch nach der Annahme. Dies geschieht nur, wenn der Implementierungsprozess grundlegende Fehler im Design aufdeckt, die vor der Annahme des PEPs nicht bemerkt wurden. Im Gegensatz zu Provisional PEPs sind diese Übergänge nur gestattet, wenn der angenommene Vorschlag *nicht* in eine Python-Version aufgenommen wurde – freigegebene Änderungen müssen stattdessen den regulären Deprecationsprozess durchlaufen (was ein neues PEP mit der Begründung für die Deprecation erfordern kann).

Einige Informationelle und Prozess-PEPs können auch den Status "Active" haben, wenn sie niemals abgeschlossen werden sollen. Z. B. PEP 1 (dieses PEP).

PEP-Pflege

Im Allgemeinen werden PEPs nach Erreichen des Status "Accepted", "Final", "Rejected" oder "Superseded" nicht mehr wesentlich modifiziert. Sobald eine Entscheidung getroffen ist, wird ein PEP als historisches Dokument und nicht als lebende Spezifikation betrachtet. Formale Dokumentation des erwarteten Verhaltens sollte an anderer Stelle gepflegt werden, z. B. in der Language Reference für Kernfeatures, der Library Reference für Standardbibliotheksmodule oder den PyPA Specifications für Packaging.

Wenn Änderungen, die auf Implementierungserfahrung und Benutzerfeedback basieren, an Standards Track PEPs im Provisional- oder (mit SC-Zustimmung) Accepted-Status vorgenommen werden, sollten sie im PEP vermerkt werden, damit das PEP die Implementierung an dem Punkt korrekt beschreibt, an dem es als Final markiert wird.

Aktive (Informational und Process) PEPs können im Laufe der Zeit aktualisiert werden, um Änderungen an Entwicklungspraktiken und anderen Details widerzuspiegeln. Der genaue Prozess, der in diesen Fällen befolgt wird, hängt von der Art und dem Zweck des betreffenden PEPs ab.

Gelegentlich kann ein zurückgestelltes oder sogar ein zurückgezogenes PEP mit größeren Aktualisierungen wiederbelebt werden, aber es ist oft besser, einfach ein neues vorzuschlagen.