Resumen

  • Python diferencia la discusión de un PEP, la resolución del Steering Council o de un PEP-Delegate aprobado, la implementación de referencia, su incorporación al repositorio principal y el control de las etapas de lanzamiento.
  • Un recibo de decisión a lanzamiento debe conservar el PEP, la autoridad, la resolución, la revisión, la rama y el artefacto como pruebas separadas, no convertir toda aceptación en una promesa de entrega.

La misma palabra puede ocultar cinco actos

Decir que «Python aceptó» una novedad puede significar que existe un borrador bien formado, que hubo una conversación pública, que una autoridad resolvió el PEP, que una implementación se incorporó a CPython o que se publicó una versión. Son acontecimientos relacionados, pero no son evidencia intercambiable para quien debe planificar un empaquetado, una migración o un contrato de soporte.

PEP 1 define el PEP como documento de diseño, mecanismo para recoger aportes y registro de las razones y disensos. El autor tiene que construir consenso. Esa obligación produce una discusión más verificable; no convierte una suma de participantes en una decisión formal ni transforma la conversación en un artefacto de lanzamiento.

Por eso conviene empezar por el acto. La revisión editorial habilita un documento; no lo acepta. La discusión prueba una propuesta; no la entrega. Una resolución delimita una decisión; no completa el código. Una revisión de repositorio identifica una implementación; no demuestra que la rama esté lista para distribución. Cada salto requiere su propia evidencia.

La delegación tiene un borde concreto

La autoridad final sobre la aceptación de los PEP corresponde al Steering Council elegido. Un core developer puede ofrecerse como PEP-Delegate para un PEP determinado. Si el Council aprueba la oferta, ese delegado puede aprobar o rechazar ese PEP. Si existen dudas sobre la idoneidad de la delegación, también pueden llevarse al Council.

No es un detalle ceremonial. La delegación concentra una decisión técnica sin borrar la responsabilidad del órgano que la concedió. Su alcance es la propuesta designada, no cada decisión sobre Python, cada cambio posterior ni cada publicación. PEP 13 describe al Council como autoridad amplia, capaz de delegar, orientada a buscar consenso y tribunal de apelación final cuando fracasan otros métodos. Precisamente por ser amplia, esa autoridad debe poder atribuirse a una acción concreta.

Una nota seria debería enlazar el PEP, la decisión, el registro de resolución y, si corresponde, la delegación. El tamaño de una discusión no sustituye ese vínculo. Participar aporta conocimiento y crítica; no añade por sí solo la facultad de comprometer una rama o una fecha de lanzamiento.

Aceptado no es Final, y Final no es una caja distribuida

PEP 1 dice que, tras aceptar un PEP, la implementación de referencia debe completarse e incorporarse al repositorio principal antes de que el estado pase a Final. Por tanto, una aceptación no acredita que el código esté terminado. El estado Final conecta una decisión con una implementación de referencia acabada; no es sólo una etiqueta más enfática.

Tampoco debe leerse cualquier estado como garantía absoluta. Un PEP aceptado provisionalmente puede ser rechazado o retirado incluso después de que cambios relacionados hayan aparecido en un lanzamiento. No demuestra estabilidad universal, adopción de terceros ni ausencia de futuras correcciones.

El ciclo de desarrollo añade una frontera distinta. Las novedades viven en la rama en desarrollo; al entrar en beta se crea una rama de mantenimiento para estabilizar el ciclo actual mientras el siguiente sigue en main. En una release candidate sólo caben correcciones revisadas de suficiente gravedad. Al cortar una versión final, sólo el release manager puede modificar esa rama. Estas reglas protegen una operación de publicación; no vuelven al release manager autor de la decisión de diseño, ni dan a la aceptación de un PEP poder para saltar la estabilización.

Un recibo que una sin confundir

La parte de decisión debería guardar número y versión del PEP, discusión canónica, autoridad que resolvió, delegación si existe, enlace de resolución y alcance. También debería anotar lo que no se decidió: versión objetivo, retroportaciones, estado del código o fecha, cuando no estén incluidos.

La parte de implementación puede añadir la revisión de referencia, repositorio, rama y pruebas públicas. La parte de lanzamiento debe añadir la rama, fase, identificador del artefacto, acto del release manager y versión publicada. Una fecha de mensaje no reemplaza una etiqueta ni un archivo identificable.

No es una propuesta de nueva obligación para Python. Es una disciplina para no transformar consenso en mandato, mandato en código finalizado o código integrado en disponibilidad operativa.

Fuentes

  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