Zusammenfassung

  • Der PEP-Prozess von Python trennt öffentliche Erörterung, Resolution durch den Steering Council oder einen genehmigten PEP-Delegate, Referenzimplementierung, Aufnahme in das Hauptquell-Repository und die Kontrollen der Release-Phasen.
  • Ein Nachweis von der Entscheidung bis zum Release sollte PEP, Entscheider, Resolution, Revision, Branch, Phase und Artefakt getrennt festhalten, statt „Accepted“ als Lieferzusage zu lesen.

Eine Entscheidung ist nicht schon die Lieferung

Die Aussage, Python habe eine Änderung angenommen, kann eine saubere PEP-Datei, eine lange Debatte, eine formelle Resolution, einen Merge in CPython oder ein fertiges Release meinen. Für die tägliche Kommunikation ist diese Verkürzung verständlich. Für Teams, die Abhängigkeiten festlegen, Pakete bauen oder Support zusagen, lässt sie die entscheidende Frage offen: Welcher Übergang ist tatsächlich belegt?

PEP 1 beschreibt einen PEP als Entwurfsdokument. Er bündelt große Vorschläge, Community-Rückmeldungen, Begründungen und abweichende Stimmen. Der Autor soll Konsens suchen und Einwände dokumentieren. Die Debatte ist daher kein beiläufiges Ritual. Sie macht technische Gründe sichtbar. Sie ist aber keine Abstimmungsurkunde und kein Beweis dafür, dass ein benennbares Release bereits existiert.

Die richtige Reihenfolge beginnt mit der Handlung. Redaktionelle Prüfung entscheidet über Form und Ablauf, nicht über die technische Annahme. Eine Diskussion prüft ein Design, nicht einen Auslieferungszweig. Eine Resolution behandelt den PEP, nicht automatisch jede Implementierungsfrage. Eine Revision zeigt Code in einem Repository, nicht notwendig einen stabilisierten Release. Jede Stufe beantwortet eine eigene Frage und braucht eine eigene Referenz.

Der Delegate entscheidet nur im verliehenen Rahmen

Die letzte Autorität über die Annahme von PEPs liegt beim gewählten Steering Council. Ein Core Developer kann sich für einen bestimmten PEP als PEP-Delegate anbieten. Billigt der Council dies, darf diese Person eben diesen PEP annehmen oder ablehnen. Bedenken gegen die Eignung können wiederum beim Council vorgebracht werden.

Das ist eine begrenzte Delegation, keine allgemeine Übertragung der Sprache an eine Person. Sie legt die Entscheidung nahe an die Fachkenntnis und bewahrt gleichzeitig einen Weg für Bestellung, Einwand und letzte Verantwortung. PEP 13 beschreibt den fünfköpfigen Council mit breiter Autorität, dem Auftrag, vor formellem Handeln Konsens zu suchen, der Möglichkeit zu delegieren und der Rolle als letzte Berufungsinstanz.

Gerade deshalb muss ein Bericht die konkrete Zuweisung nennen. Aus der Existenz des Council folgt nicht, dass jeder Commit eine Council-Entscheidung ist. Aus dem Namen eines Delegierten folgt nicht, dass ein Branch freigegeben oder eine Version versprochen wurde. Die Reichweite ist der bezeichnete PEP und die bezeichnete Resolution.

Statuswörter tragen unterschiedliche Beweise

Nach PEP 1 muss die Referenzimplementierung nach der Annahme vollständig sein und in das Hauptquell-Repository aufgenommen werden, bevor der Status Final lautet. Accepted beweist folglich keine fertige Implementierung. Final verbindet einen Designbeschluss mit einer abgeschlossenen Referenzimplementierung; es ist nicht bloß eine emphatischere Wiederholung von Accepted.

Auch ein Provisional-Status ist keine pauschale Gewährleistung. Ein vorläufig angenommener PEP kann verworfen oder zurückgezogen werden, nachdem zugehörige Änderungen in einem Python-Release erschienen sind. Weder eine Statuszeile noch ein Merge beweist universelle Kompatibilität, breite Nutzung oder Fehlerfreiheit.

Der Development Guide trennt den Release-Übergang zusätzlich. Neue Funktionen liegen im Entwicklungs-Branch. Mit der ersten Beta entsteht ein Maintenance-Branch, damit der aktuelle Zyklus stabilisiert und der nächste auf main fortgeführt werden kann. Für einen Release Candidate sind Änderungen auf begutachtete, ausreichend schwerwiegende Fehlerbehebungen beschränkt. Beim Schneiden eines finalen Releases darf nur der Release Manager den Branch ändern. Diese Regel schützt einen bestimmten Stabilisierungsvorgang; sie verlegt nicht die PEP-Entscheidung in die Release-Rolle.

Ein nachvollziehbarer Übergangsbeleg

Der Entscheidungsteil sollte PEP-Nummer und -Version, die maßgebliche Diskussion, Entscheider, Delegation falls vorhanden, Resolutionslink und Status enthalten. Was nicht entschieden wurde — Zielversion, Backports, Implementierungsstand oder Termin — gehört ebenfalls klar benannt. Der Implementierungsteil ergänzt Referenzrevision, Repository, Branch sowie öffentliche Tests oder Reviews. Der Release-Teil ergänzt Branch, Phase, Artefaktkennung, Handlung des Release Managers und veröffentlichte Version.

Das ist keine neue Python-Pflicht. Es ist eine redaktionelle Begrenzung gegen drei falsche Schlüsse: Beteiligung wird nicht zu Autorität, Autorität nicht zu fertigem Code und integrierter Code nicht zu einem verfügbaren Release.

Quellen

  1. PEP 1 — PEP Purpose and Guidelines
  2. PEP 13 — Python Language Governance
  3. Python Developer’s Guide — Development cycle
  4. Lu Heng, The Multi-Stakeholder Mirage
  5. Lu Heng, Running-Code Primacy