Validador de PEP (Python)

PEP: como o Python evolui, uma proposta de cada vez

Uma PEP (Python Enhancement Proposal) e o documento formal que a comunidade Python usa para discutir e adotar mudancas na linguagem, novas bibliotecas, processos e convencoes. PEPs sao deliberadamente modeladas na tradicao das RFCs da IETF, mas restritas ao Python: de uma nova sintaxe a um campo de metadados de packaging, tudo passa por uma PEP antes de entrar no CPython. Este validador checa o formato PEP NNN e ajuda a localizar propostas conhecidas.

O proprio processo e definido pela PEP 1, escrita em 2000 por Barry Warsaw, Jeremy Hylton e David Goodger. Ela documenta as meta-regras: como submeter, como a discussao corre no python-dev, como o Steering Council (antes o BDFL Guido van Rossum, que se aposentou do cargo em 2018) decide Accepted/Rejected/Deferred, e onde mora a implementacao.

Formato e regra de validacao

Um identificador PEP e a string literal PEP seguida de um inteiro positivo (sem zeros a esquerda, sem teto rigido, hoje na faixa dos 700+). O validador tambem pode aceitar so o numero. Regex canonico:

/^PEP\s?\d{1,4}$/i        // PEP 8, PEP484, pep 695
/^\d{1,4}$/               // somente numero: 8

Como nas RFCs, PEPs nao tem checksum: a unica checagem real e existencia, e ela exige consulta em peps.python.org. Numeros nunca sao reaproveitados — PEPs retiradas ou rejeitadas mantem o slot para sempre.

Tipos de PEP: Standards Track, Informational, Process

• Standards Track — propoe um recurso novo da linguagem ou da stdlib (PEP 484 type hints, PEP 572 operador walrus :=).
• Informational — fornece guia ou contexto (PEP 20 The Zen of Python).
• Process — descreve como a comunidade funciona (a propria PEP 1, a serie PEP 8000 sobre governanca).

Cada PEP tem um campo Status que flui: Draft -> Accepted -> Final (ou Rejected, Withdrawn, Deferred, Superseded). PEPs Process e Informational podem ficar em Active indefinidamente.

PEPs famosas que todo Pythonista deve conhecer

• PEP 8 — Style Guide. Indentacao de 4 espacos, snake_case para funcoes, linha maxima 79 (ou 99 em projetos modernos). Aplicada por ruff, flake8, black.
• PEP 20 — The Zen of Python (import this em qualquer REPL).
• PEP 257 — convencoes para docstrings.
• PEP 333 / 3333 — WSGI, o gateway entre web servers e apps Python.
• PEP 484 — type hints (2014), fundamento do mypy, pyright e da tipagem moderna do Python.
• PEP 517 / 518 / 621 — o ecossistema do pyproject.toml: sistema de build, escolha de backend e metadados do projeto.
• PEP 572 — operador walrus :=, polemico o suficiente para precipitar a aposentadoria do Guido como BDFL.
• PEP 695 — sintaxe de generics (class Stack[T]:) lancada no Python 3.12.
• PEP 703 — tornar o GIL opcional. Disponivel como build experimental no Python 3.13 (out/2024).

Governanca: BDFL, Steering Council, python-dev

De 1991 a 2018 o Python teve um BDFL (Benevolent Dictator For Life) — Guido van Rossum — que tinha a palavra final em toda PEP. Apos a briga do walrus (PEP 572) o Guido renunciou e a comunidade adotou um Steering Council eleito anualmente pela PEP 13. A discussao hoje acontece no discuss.python.org (substituindo a lista python-dev).

PEP vs RFC vs JEP

• PEP — so Python, alcanca linguagem + stdlib + packaging.
• RFC — IETF, rege protocolos de Internet e e consumida por todas as linguagens.
• JEP — Java Enhancement Proposal, equivalente Oracle/OpenJDK para a JVM.
• Propostas TC39 — equivalente do JavaScript, em estagios 0 a 4.
• RFCs/SIPs — Rust e Scala mantem seus proprios repositorios de RFC com o mesmo espirito.

Tooling e enforcement

A PEP 8 e aplicada por linters (ruff, flake8) e formatadores (black, autopep8). Type hints da PEP 484 sao checados por mypy, pyright/Pylance e pyre. PEPs de packaging (517, 518, 621) sao implementadas por pip, uv, hatchling e poetry. Na comunidade brasileira, python.org.br, a conferencia Python Brasil e os GruPys locais (Grupy-SP, Grupy-RJ) ajudam quem esta comecando a navegar o ecossistema de PEPs.

FAQ

PEPs sao de leitura gratuita?

Sim. Todas as PEPs sao HTML em dominio publico em peps.python.org, geradas a partir de um repositorio Git sob a Python Software Foundation.

A PEP 8 e obrigatoria?

E uma convencao, mas na pratica todo projeto Python a impoe via CI. Ferramentas modernas como ruff conseguem autocorrigir a maior parte das violacoes em milissegundos. O proprio CPython segue a PEP 8 estritamente.

Qual e o Python estavel atual?

Python 3.13 (lancado em outubro de 2024) e o mais recente estavel. Ele traz o build experimental free-threaded da PEP 703 e um preview do JIT da PEP 744. O 3.14 esta em alpha no momento.

A PEP 1 ja foi substituida?

A PEP 1 continua descrevendo o processo hoje, com revisoes menores. A PEP 12 define o template de formato (reStructuredText / Markdown) das novas PEPs. As duas se complementam, em vez de uma substituir a outra.

Qualquer um pode submeter uma PEP?

Sim. O fluxo e: discutir no discuss.python.org ate emergir rough consensus, conseguir um sponsor entre os core devs, abrir um pull request no repo python/peps e aguardar a decisao do Steering Council. A maioria das PEPs rejeitadas e rejeitada por falta de esforco de implementacao, nao pela ideia em si.