3 puntos por GN⁺ 2026-03-10 | 1 comentarios | Compartir por WhatsApp
  • Se fusionó un cambio en el repositorio de uv para dejar explícito en la documentación que PyPy no se está desarrollando activamente
  • El autor de la propuesta mencionó, basándose en un issue del proyecto numpy, que PyPy está siendo eliminado gradualmente
  • A la documentación se le agregó una advertencia que dice: “PyPy ya no se desarrolla activamente y solo es compatible hasta Python 3.11”
  • Después, en la comunidad, desarrolladores de PyPy respondieron que el mantenimiento continúa, pero que por falta de personal es difícil seguir el ritmo de las versiones de CPython
  • El proyecto ajustó la redacción de “unmaintained” a “not actively developed” para reflejar la situación con mayor precisión

Resumen del Pull Request

  • konstin creó un PR para agregar una advertencia sobre PyPy a la documentación del proyecto uv
    • Como motivo, indicó que “PyPy ya no se desarrolla activamente y también está siendo eliminado gradualmente en numpy”
    • Explicó que no hay un comunicado oficial, pero que el issue relacionado de numpy fue planteado por un desarrollador de PyPy
  • En la documentación (docs/concepts/python-versions.md) se añadió el siguiente contenido
    • PyPy ya no se desarrolla activamente y solo es compatible hasta Python 3.11
  • El PR, compuesto por 4 commits, fue fusionado a la rama main el 22 de enero de 2026

Debate en la comunidad

  • Algunos colaboradores señalaron que la advertencia parecía duplicada, y luego se corrigió para que apareciera solo una vez
  • Tras la fusión, la comunidad de PyPy y desarrolladores externos reaccionaron a través de comentarios en GitHub
    • stuaxo citó declaraciones de desarrolladores de PyPy y sostuvo que “PyPy está en mantenimiento; simplemente va más lento que CPython”
    • Foxboron preguntó: “¿Se contactó a los mantenedores de PyPy antes de fusionarlo?”
    • vitorsr citó una declaración de mattip, desarrollador principal de PyPy, diciendo que “se necesitan contribuyentes o apoyo financiero”
  • HaoZeke pidió retirar el PR, argumentando que “se fusionó sin discusión”

Respuesta del proyecto

  • charliermarsh explicó que el título del PR se cambió de “unmaintained” a “not actively developed”
  • zanieb aclaró que no hubo mala intención, y dijo que “en el issue de numpy un desarrollador principal de PyPy mencionó directamente que no se desarrolla activamente”
  • mattip (desarrollador principal de PyPy) dijo que “la redacción actual refleja la situación de forma justa” y aceptó mantener la frase
    • Aun así, mencionó que si PyPy se actualiza a Python 3.11.15, el PR podría revertirse

Impacto después de la fusión

  • Este cambio se incluyó en el lanzamiento de uv 0.9.27 y se reflejó como una actualización de la documentación
  • Homebrew y varios bots de automatización hicieron referencia a ese PR, por lo que la advertencia sobre PyPy quedó incluida en la documentación oficial

1 comentarios

 
GN⁺ 2026-03-10
Opiniones de Hacker News
  • Soy desarrollador principal de PyPy. Si alguien quiere ayudar, ya sea con financiamiento o contribuyendo código, agradecería que revisara cómo contactarnos
    • Estaría bien que hubiera una sección de donaciones más visible en el sitio. Algo como los niveles de patrocinio escalonados del navegador Ladybird también podría funcionar. Yo quise donar un poco, pero fue difícil encontrar dónde hacerlo
    • Acabo de donar. Gracias a todo el equipo de PyPy. Uso PyPy con frecuencia en mi app y, en tareas con mucha carga de cómputo, suele ser más de 5 veces más rápido que CPython. Lo que en CPython tomaba 5 minutos, en PyPy termina en segundos
    • También quisiera proponer otra cosa. Sé que PyPy es rápido en tareas CPU-bound, pero creo que también podría mostrar mejor rendimiento en tareas I/O-bound. Estaría bien crear una página de benchmarks que compare asyncio y CPython en cosas como rendimiento de solicitudes HTTP. También sería interesante contar con una herramienta automatizada para medir directamente el rendimiento de PyPy en la web
    • En el sitio aparece en grande la frase mantenimiento discontinuado
  • PyPy no es un proyecto abandonado. Se siguen corrigiendo errores y mejorando el JIT. Pero los desarrolladores principales que quedan no dan abasto para seguir el ritmo de cambios acelerado de CPython. Se necesitan nuevos colaboradores para dar soporte a nuevas versiones. Por suerte, un nuevo contribuidor ya está trabajando en la versión 3.12
    • CPython ahora se ha vuelto casi un proyecto comercializado. Algunos desarrolladores excluyen a otros, y muchos proyectos financiados por empresas desaparecen a los 5 años. La gente más brillante ya se fue. Reescribir unicodeobject.c por 150ª vez todavía pasa, pero lo demás es difícil de seguir
    • La frase incorporada en la documentación es más concisa que el título del PR: dice “ya no se desarrolla activamente”
  • PyPy es de verdad un logro asombroso. Mientras que el equipo de Faster CPython de Microsoft apenas logró una mejora de 1.5x en 4 años, PyPy lleva décadas siendo más de 5 veces más rápido. Pero parece recibir menos atención porque su objetivo principal se parece más a un proyecto de investigación (meta-tracing, STM, etc.), y porque al equipo de CPython no le interesan mucho otras implementaciones
    • El éxito del ecosistema Python se debe a bibliotecas de extensiones en C como SciPy, pandas y TensorFlow. CPython ofrecía una API de C que permitía acelerar fácilmente este tipo de bibliotecas. El CFFI de PyPy no resultó lo bastante atractivo para que lo adoptaran proyectos grandes, y HPy llegó demasiado tarde, cuando PyPy ya había perdido impulso
    • El proyecto Faster Python podría haber avanzado más, pero Microsoft lo frenó el año pasado cuando despidió masivamente a los equipos relacionados con lenguajes para perseguir el boom de la IA
    • Nosotros llevamos más de 10 años usando PyPy en producción en componentes centrales del sistema
    • PyPy es excelente en benchmarks, pero en desarrollo real a gran escala tiene demasiados problemas de compatibilidad. A la mayoría le impresiona en pruebas de rendimiento, pero falla en apps reales. Como el GC es lazy, recursos como los descriptores de archivo no se liberan a tiempo, y eso provoca agotamiento de recursos con facilidad. El problema es que estas diferencias importantes no están documentadas
  • Para quien se confunda con los nombres, PyPI es el índice de paquetes de Python y PyPy es una “implementación alternativa de Python rápida y con alta compatibilidad”. Aun así, el lanzamiento de la versión 3.12 está retrasado por falta de desarrolladores (discusión relacionada)
    • Gracias por la aclaración. Sobre todo porque en el issue del repositorio de uv se mezclaban PyPi y PyPy y era confuso
    • Me recuerda a la relación entre Cython y CPython
    • mypy es un “verificador de tipos estático para Python”. Como el RPython de PyPy también maneja tipado estático, antes los confundía seguido. Hace poco también conocí mypyc, y sentí que por fin se cerró el circuito en mi cabeza
    • Realmente tienen una pésima habilidad para poner nombres
  • Es interesante que “ya no se desarrolla activamente como proyecto voluntario” haya pasado a “mantenimiento discontinuado”
    • Como referencia, PyPy ha tenido entre 2 y 4 commits al mes desde octubre del año pasado, y la última release fue en julio de 2025 (historial de commits, lista de tags)
    • Respeto a los contribuidores de PyPy, pero la evaluación de “discontinuado” me parece una descripción bastante justa
  • Sería realmente una pena que PyPy desapareciera. Ojalá los resultados útiles de toda esa investigación se hayan trasladado a CPython
    • El REPL puro en Python que comenzó en PyPy fue refinado en CPython, y las lecciones de HPy también se están reflejando poco a poco en CPython. Además, gracias a PyPy se corrigieron muchos bugs sutiles en la biblioteca estándar de CPython
    • Pero el enfoque es tan distinto que probablemente la mayoría de las tecnologías no se habrían podido portar directamente a CPython
  • Lo leí como PyPi y por un momento casi me da un infarto
  • Quizá ahora valga más la pena invertir tiempo y dinero en RustPython (sitio oficial, GitHub)
    • Pero RustPython es más lento que CPython; no veo por qué usarlo
  • Al final, el desarrollo se mueve con dinero. ¿Por qué todavía no existe un sistema para donar a los desarrolladores de todo el árbol de dependencias? Si este tipo de problemas se acumula, al final mantener todo se va a volver muy difícil
  • Gracias por todo el esfuerzo del equipo de PyPy. Yo también voy a buscar una forma de ayudar