Resumo

  • O processo de Python distingue discussão pública, resolução do Steering Council ou de um PEP-Delegate aprovado, implementação de referência, integração ao repositório principal e controles próprios do ciclo de lançamento.
  • Um recibo de decisão a lançamento deve ligar, sem confundir, PEP, autoridade, resolução, revisão, branch, estágio e artefato; “aceita” não equivale a “entregue”.

O problema de uma frase curta

Uma nota que diz que Python aceitou uma mudança pode se referir a um PEP editado, a uma discussão extensa, a uma decisão formal, a código em CPython ou a uma versão publicada. A frase não é necessariamente enganosa, mas não oferece ao leitor a informação necessária para inferir compatibilidade, calendário, distribuição ou suporte.

PEP 1 define a PEP como documento de desenho: ela organiza uma proposta, a contribuição da comunidade, a justificativa e as discordâncias. Seu autor procura formar consenso e deixar as objeções visíveis. Esse trabalho melhora a qualidade da decisão. Não substitui a autoridade que a toma nem cria uma prova de que uma implementação ou um pacote final já existem.

É mais seguro começar pelo ato, não pelo prestígio de quem participa. A aprovação editorial de um texto não é aprovação de seu conteúdo. Discussão não é mandato. Uma resolução não é código concluído. Uma mudança em repositório não é release. Cada fronteira é útil porque permite saber qual pergunta foi realmente respondida.

Delegar não é distribuir uma autoridade ilimitada

PEP 1 reserva ao Steering Council eleito a autoridade final sobre a aprovação de PEPs. Um core developer pode se oferecer como PEP-Delegate de uma PEP específica. Uma vez que o Council aprove a indicação, a pessoa pode aprovar ou rejeitar aquela PEP; preocupações com a adequação do delegado podem ser levadas ao próprio Council.

Trata-se de uma delegação limitada. Ela aproxima a decisão de experiência técnica sem eliminar o órgão que concede, controla e responde pela delegação. O mandato vale para a proposta indicada. Não autoriza a pessoa a decidir qualquer versão, qualquer branch, nem a prometer uma data de lançamento.

PEP 13 situa o Council como órgão de ampla autoridade, com dever de buscar consenso antes de agir formalmente, poder de delegar e função de última instância. Essa arquitetura só conserva sentido se o registro puder indicar quando foi o Council, quando foi um delegado aprovado e qual PEP estava no escopo. Não se pode emprestar a autoridade do Council a cada commit, nem usar o nome de um delegado como carimbo de disponibilidade operacional.

A cadeia de estados tem mais de uma porta

Depois de uma PEP ser aceita, PEP 1 exige uma implementação de referência completa e sua incorporação ao repositório principal para que o estado se torne Final. Portanto, Accepted não comprova que a implementação está pronta. Final conecta decisão e implementação de referência; não é uma forma enfática de dizer que a discussão acabou.

Uma PEP provisoriamente aceita pode ainda ser rejeitada ou retirada mesmo depois de mudanças relacionadas aparecerem em uma release. Nenhum desses estados certifica adoção universal, maturidade comercial ou ausência de problemas futuros.

O guia de desenvolvimento dá à publicação outra fronteira. Recursos avançam no branch em desenvolvimento. Na entrada em beta, cria-se um branch de manutenção, permitindo que o próximo ciclo siga em main enquanto o atual é estabilizado. Em release candidate, mudanças ficam limitadas a correções graves e revisadas. No corte de uma versão final, somente o release manager pode alterar o branch. É uma regra para proteger o artefato em estabilização, não para rever ou ampliar a resolução de desenho de uma PEP.

Um recibo que permita reconstituir a passagem

O trecho de decisão deve registrar número e versão da PEP, discussão canônica, autoridade decisória, delegação aplicável, resolução e escopo. O que não foi decidido — versão-alvo, backports, término da implementação, data — também deve ficar claro. O trecho de implementação deve apontar para revisão de referência, repositório, branch e testes públicos. O trecho de lançamento deve identificar branch, estágio, artefato, ato do release manager e versão publicada.

Essa recomendação não cria uma norma Python. Ela evita três atalhos: transformar participação em autoridade, autoridade em código pronto e código integrado em garantia de lançamento. Uma cadeia curta e verificável é mais honesta do que uma única palavra com força emprestada.

Fontes

  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