Résumé

  • Le processus PEP distingue la discussion, la décision du Steering Council ou d’un PEP-Delegate approuvé, l’implémentation de référence, son intégration au dépôt principal et les contrôles propres aux branches de publication.
  • Un reçu de décision à publication doit garder séparés le PEP, le décideur, la résolution, la révision de code, la branche et l’artefact, plutôt que de lire « accepté » comme « livré ».

Le raccourci « Python a accepté » ne suffit pas

Une phrase disant que Python a accepté une idée peut parler d’un document mis en forme, d’une discussion ouverte, d’une résolution, d’un changement dans CPython ou d’un paquet final. Ces étapes peuvent être proches; elles répondent pourtant à des questions différentes. Pour une équipe qui doit empaqueter, déployer ou engager un support, elles ne constituent pas la même preuve.

PEP 1 présente le PEP comme un document de conception qui recueille l’avis de la communauté et conserve la raison des choix, y compris les désaccords. L’auteur doit chercher le consensus et en garder trace. Cela donne à la décision une base visible. Ce n’est ni la décision elle-même, ni un bon de livraison pour une version donnée.

L’ordre sain est de demander d’abord quel acte est en cause. Une discussion peut tester une idée. Une relecture éditoriale peut rendre un texte publiable. Une résolution peut accepter ou rejeter une proposition. Une révision peut rendre une implémentation disponible. Une publication peut fixer un artefact. L’autorité ne se transfère pas automatiquement d’une colonne à la suivante.

Le PEP-Delegate reçoit une mission bornée

Le Steering Council élu conserve l’autorité finale sur l’acceptation des PEP. Un core developer peut se proposer comme PEP-Delegate pour une proposition déterminée; si le Council accepte l’offre, cette personne peut approuver ou rejeter ce PEP. Les inquiétudes sur cette délégation peuvent elles-mêmes revenir au Council.

Cette construction ne fait ni du délégué un souverain du langage, ni du Council un décor. Elle rapproche une décision du contexte technique tout en gardant une voie d’attribution, de contrôle et d’appel. La portée reste le PEP désigné. Elle ne devient pas un mandat sur toutes les futures versions, toutes les branches ou toutes les questions de conception.

PEP 13 donne le cadre : le Council dispose d’une large autorité, cherche le consensus avant l’acte formel, peut déléguer et sert de recours final lorsque les autres méthodes échouent. La valeur de ce cadre dépend de sa traçabilité. L’existence du Council ne transforme pas chaque commit en décision collective; le nom d’un délégué ne transforme pas une résolution bornée en promesse de publication.

« Accepted », « Final » et « released » ne disent pas la même chose

PEP 1 exige qu’une implémentation de référence soit achevée et intégrée au dépôt principal avant qu’un PEP accepté passe à Final. Accepted ne prouve donc pas que le code est terminé. Final associe une décision à une implémentation de référence achevée; ce n’est pas un simple embellissement du statut antérieur.

La prudence est encore nécessaire pour un PEP provisoirement accepté : il peut être rejeté ou retiré après que des changements liés ont été inclus dans une publication. Un statut n’est pas une garantie générale de stabilité, d’adoption ou de compatibilité. Il faut lui laisser le sens précis que lui donnent les règles.

Le guide de développement sépare également le dépôt principal, les branches de maintenance et les phases de prépublication. À l’entrée en bêta, une branche de maintenance permet de stabiliser le cycle courant pendant que le suivant avance sur main. En release candidate, seules des corrections de bogues revues peuvent être acceptées. Lors de la coupe d’une publication finale, seul le release manager peut modifier la branche. Cette discipline protège une fenêtre de stabilisation; elle ne réécrit pas la décision de conception du PEP.

Un reçu de décision à publication

Pour la résolution, le reçu devrait désigner le PEP et sa version, le fil de discussion, le décideur, la délégation éventuelle, le lien de résolution et le statut. Il devrait aussi dire explicitement ce que cette résolution ne fixe pas : version cible, état de l’implémentation, rétroportages ou date de livraison, lorsque ces éléments ne sont pas décidés.

Pour l’implémentation, il devrait ajouter la révision de référence, le dépôt, la branche et les éléments de test publics. Pour la publication, il devrait ajouter la branche, le stade, l’identifiant de l’artefact, l’acte du release manager et la version publiée. Une date de discussion ne remplace pas une archive, une étiquette ou un paquet stable.

Il ne s’agit pas d’imposer une nouvelle bureaucratie à Python. C’est une discipline éditoriale minimale : ne pas transformer une participation en mandat, une résolution en code achevé, ni une intégration de code en publication utilisable.

Sources

  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