Las constantes predeclaradas de Python son algo raras

Artículo original ↗ Discusión en Hacker News ↗

La forma en que Python maneja constantes integradas como `True`, `False`, `None`, `Ellipsis` y `__debug__` expone algunos casos límite sorprendentes, como código condicional que se elimina en tiempo de compilación o rarezas históricas como la reasignación de booleanos en versiones tempranas. Los comentaristas usan estos ejemplos para examinar compensaciones de diseño más amplias en Python: su “equipaje” acumulado, las esquinas extrañas de los sistemas de tipos y async, y un empaquetado notoriamente desordenado, frente a sus fortalezas como lenguaje accesible, con “baterías incluidas” y un ecosistema potente para scripting, trabajo con datos y código de pegamento. El intercambio también contrasta Python con lenguajes como PHP, JavaScript, Ruby y Haskell, destacando las tensiones recurrentes entre la elegancia teórica del diseño de lenguajes, la compatibilidad hacia atrás y la usabilidad pragmática a escala.

Constantes especiales y compilación condicional

  • La discusión se centra en las “constantes predeclaradas” de Python: True, False, None (palabras clave) frente a Ellipsis, NotImplemented, __debug__ (identificadores con tratamiento especial).
  • Se destaca que __debug__ es especialmente extraño: los bloques if __debug__: se eliminan por completo al compilar bajo PYTHONOPTIMIZE / -O, lo que lo convierte en una forma de compilación condicional junto con assert.
  • Esta es la razón por la que está prohibido asignar a __debug__: el compilador asume que es constante al eliminar código.
  • Varios comentaristas admiten que nunca habían oído hablar de __debug__, ni de su interacción con assert, y señalan el potencial de errores de seguridad reales cuando assert se usa mal para comprobaciones críticas.
  • También se menciona TYPE_CHECKING, que llegará en 3.15, como otra constante predeclarada que se comporta como Ellipsis/NotImplemented.

Rarezas históricas de los booleanos y “equipaje” de diseño

  • El Python temprano no tenía True/False; los usuarios los definían como 1/0. Python 2 permitía reasignarlos; Python 3 los convirtió en palabras clave.
  • bool sigue siendo una subclase de int, lo que continúa sorprendiendo a la gente y ha causado errores.
  • Punto más amplio: adaptar bool/null a posteriori en un lenguaje es difícil; se citan C y Python como ejemplos.
  • Algunos comentan arrepentimientos más amplios de diseño de lenguajes: falta de matrices multidimensionales integradas, arrays de bits y tipos vectoriales pequeños estandarizados.

Python frente a otros lenguajes y su evolución

  • Un sector sostiene que Python es viejo, lento, frágil, con tipado débil y empaquetado caótico; afirman que comunidades como la de PHP han evolucionado de forma más agresiva y han aprendido mejores lecciones (por ejemplo, tipos obligatorios, herramientas unificadas).
  • Otros enumeran mejoras sustanciales en Python: type hints, async/await, trabajo de rendimiento, f-strings, pattern matching, operadores de fusión de diccionarios, dataclasses, trabajo para eliminar el GIL, pathlib, etc.
  • Una visión crítica sostiene que estas características a menudo copian ideas sin las semánticas clave (tipos no obligatorios, pattern matching no exhaustivo, “function coloring” de async), llamándolas “anti-features”.
  • Son frecuentes las comparaciones con JavaScript, PHP, Ruby, Racket/Scheme/Haskell; las opiniones varían sobre cuál es “más raro”, más consistente o más amigable para principiantes.

Amigabilidad para principiantes y nichos de uso

  • Algunos dicen que Python está demasiado lleno de casos límite para ser un buen primer lenguaje; otros sostienen que su REPL, la biblioteca estándar “baterías incluidas”, la legibilidad y el soporte para Windows lo convierten en un excelente lenguaje de enseñanza y de “pegamento”.
  • La indentación significativa, la truthiness y el duck typing se califican como “raros” por algunos y como “consistentes y aprendibles” por otros.

Ecosistema, empaquetado e imports

  • Hay muchas quejas sobre la gestión de dependencias, virtualenvs y la fragmentación de herramientas; uv recibe elogios como una mejora importante, aunque aún no es estándar.
  • La semántica de imports (__name__ == "__main__", paquetes frente al sistema de archivos, __init__.py, imports relativos) se ve como poco intuitiva por algunos, pero se defiende como coherente con el modelo de módulos de Python.