As constantes pré-declaradas do Python são meio estranhas

Artigo original ↗ Discussão no Hacker News ↗

O tratamento que o Python dá a constantes embutidas como `True`, `False`, `None`, `Ellipsis` e `__debug__` expõe alguns casos-limite surpreendentes, como código condicional sendo removido na compilação ou peculiaridades históricas como a reatribuição de booleanos nas primeiras versões. Os comentaristas usam esses exemplos para examinar trade-offs mais amplos no design do Python: sua “bagagem” acumulada, cantos estranhos dos sistemas de tipos e async, e o empacotamento notoriamente bagunçado, versus seus pontos fortes como uma linguagem acessível, com batteries included, e um ecossistema poderoso para scripting, trabalho com dados e código de cola. A troca também contrasta Python com linguagens como PHP, JavaScript, Ruby e Haskell, destacando tensões recorrentes entre elegância teórica de linguagem, compatibilidade com versões antigas e usabilidade pragmática em escala.

Constantes especiais e compilação condicional

  • A discussão gira em torno das “constantes pré-declaradas” do Python: True, False, None (palavras-chave) versus Ellipsis, NotImplemented, __debug__ (identificadores com tratamento especial).
  • __debug__ é destacado como especialmente estranho: blocos if __debug__: são eliminados completamente sob PYTHONOPTIMIZE / -O, tornando-o uma forma de compilação condicional junto com assert.
  • É por isso que atribuir a __debug__ é proibido: o compilador assume que ele é constante ao eliminar código.
  • Vários comentaristas admitem que nunca tinham ouvido falar de __debug__, nem de sua interação com assert, e observam o potencial de bugs reais de segurança quando assert é usado de forma indevida para verificações críticas.
  • Também é mencionada a futura TYPE_CHECKING na 3.15 como outra constante pré-declarada que se comporta como Ellipsis/NotImplemented.

Esquisitices históricas dos booleanos e “bagagem” de design

  • O Python inicial não tinha True/False; os usuários os definiam como 1/0. O Python 2 permitia reatribuí-los; o Python 3 os transformou em palavras-chave.
  • bool ainda é uma subclasse de int, o que continua surpreendendo as pessoas e já causou bugs.
  • Ponto mais amplo: adaptar bool/nulo em uma linguagem é difícil; C e Python são citados como exemplos.
  • Alguns discutem arrependimentos mais amplos de design de linguagem: falta de arrays multidimensionais embutidos, bit arrays e tipos vetoriais pequenos padronizados.

Python versus outras linguagens e evolução

  • Um lado argumenta que Python é antiga, lenta, frágil, com tipagem fraca e empacotamento caótico; eles afirmam que comunidades como a do PHP evoluíram de forma mais agressiva e aprenderam lições melhores (por exemplo, tipos impostos, ferramentas unificadas).
  • Outros listam melhorias substanciais do Python: type hints, async/await, trabalho de desempenho, f-strings, pattern matching, operadores de merge de dict, dataclasses, trabalho para remover o GIL, pathlib, etc.
  • Uma visão crítica sustenta que esses recursos muitas vezes copiam ideias sem as semânticas-chave (tipos não impostos, pattern matching não exaustivo, “function coloring” do async), chamando-os de “anti-features”.
  • Comparações com JavaScript, PHP, Ruby, Racket/Scheme/Haskell são frequentes; as opiniões variam sobre qual é “mais estranho”, mais consistente ou mais amigável para iniciantes.

Amigabilidade para iniciantes e nichos de uso

  • Alguns dizem que o Python tem casos-limite demais para ser uma boa primeira linguagem; outros argumentam que seu REPL, a stdlib “batteries-included”, a legibilidade e o suporte ao Windows o tornam uma excelente linguagem de ensino e de “cola”.
  • Indentação significativa, truthiness e duck typing são chamados de “estranhos” por alguns, “consistentes e aprendíveis” por outros.

Ecossistema, empacotamento e imports

  • Há muitas reclamações sobre gerenciamento de dependências, virtualenvs e ferramentas fragmentadas; uv é elogiado como uma grande melhoria, mas ainda não é padrão.
  • A semântica de importação (__name__ == "__main__", pacotes versus sistema de arquivos, __init__.py, imports relativos) é vista como pouco intuitiva por alguns, mas defendida como consistente com o modelo de módulos do Python.