--- service: "Publicasta" schema_version: "1.0" article_id: 658 title: "PyPy 8.0 incorpora soporte para Python 3.12, pero la verdadera prueba está en el ecosistema de extensiones" language: "es" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=es" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=es" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=es" channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar" channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-21T07:00:20+00:00" updated_at: "2026-09-21T07:00:20+00:00" translations: - language: "ar" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=ar" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=ar" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=ar" - language: "de" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=de" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=de" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=de" - language: "en" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=en" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=en" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=en" - language: "es" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=es" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=es" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=es" - language: "fr" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=fr" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=fr" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=pl" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=pl" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=ru" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=ru" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=zh" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=zh" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=zh" --- # PyPy 8.0 incorpora soporte para Python 3.12, pero la verdadera prueba está en el ecosistema de extensiones > PyPy 8.0 avanza en compatibilidad: Python 3.12 llega en beta, Linux adopta glibc 2.28 y el proyecto prepara el uso de ruedas cp312-abi3 de CPython. La promesa es importante, pero no convierte cualquier paquete en compatible automáticamente. PyPy 8.0 merece atención por una razón que es fácil pasar por alto al mirar el número de versión. El proyecto no se limita a distribuir otro intérprete de Python más rápido. También intenta reducir uno de los costes persistentes de elegir PyPy: la distancia entre un entorno de ejecución compatible con el lenguaje Python y el enorme universo de paquetes que dependen de la API C de CPython. ![Ilustración editorial de un entorno de ejecución inspirado en PyPy conectado mediante un puente de compatibilidad a paquetes estandarizados de extensiones de Python.](https://publicasta.com/storage/projects/10/pages/658/2026/09/cfa20102-4c12-403b-9c6f-3964594b9ac2.webp) La versión, publicada el 19 de septiembre de 2026, incorpora un intérprete de Python 3.12 en calidad beta, mantiene variantes para Python 3.11 y Python 2.7, y cambia la base de compilación de Linux a glibc 2.28. Más importante aún, el equipo de PyPy afirma que el nuevo modelo de objetos de Python 3.12 contiene las piezas necesarias para utilizar ruedas `cp312-abi3` creadas para la API limitada de CPython. El trabajo restante no se concentra únicamente en PyPy: el mecanismo de importación, los instaladores y los sistemas de compilación de paquetes deben coincidir en que esas ruedas son candidatas válidas. Eso convierte PyPy 8.0 en una versión útil para la experimentación y para pruebas de producción acotadas. No es una instrucción universal para sustituir CPython. La pregunta práctica es más concreta: ¿puede el conjunto de dependencias de tu aplicación ejecutarse en PyPy 8.0 sin recurrir a compilaciones desde código fuente, extensiones nativas sin soporte o supuestos de ejecución que solo se cumplen bajo CPython? ## Qué cambia en PyPy 8.0 PyPy describe la versión 8.0.0 como una versión principal organizada alrededor de tres líneas de intérprete: PyPy2.7, PyPy3.11 y PyPy3.12. La implementación de Python 3.12 está etiquetada explícitamente como beta, de modo que conviene tratarla como una plataforma para pruebas de compatibilidad y no como sustituto automático de un despliegue maduro de CPython. La línea de Python 3.11 sigue disponible, aunque el proyecto señala que, salvo problemas de seguridad, esta será previsiblemente su última versión compatible con Python 3.11. La nota oficial de la versión ofrece dos motivos de infraestructura para el cambio de versión principal. En primer lugar, los servidores de compilación de Linux utilizan ahora imágenes manylinux 2.28 basadas en AlmaLinux 8 y glibc 2.28, con GCC 14 en lugar de la cadena de herramientas anterior, basada en GCC 5. Los archivos comprimidos compilados resultantes requieren glibc 2.28 o posterior. Es una base razonable para muchas distribuciones actuales, pero sigue siendo una restricción de despliegue: las imágenes empresariales antiguas, los dispositivos heredados y las bases de contenedor congeladas deben comprobarse, no darse por compatibles. En segundo lugar, PyPy ha cambiado la forma en que presenta su representación interna de objetos a las extensiones C. Las versiones anteriores exponían una extensión específica de PyPy dentro de la estructura `PyObject`, de manera que difería de la disposición de CPython. En la versión 8.0, el campo específico de PyPy queda oculto en un prefijo situado antes del puntero que se entrega a los módulos de extensiones C. El objetivo declarado es que PyPy pueda utilizar ruedas `cp312-abi3` producidas para CPython 3.12 y posteriores, siempre que esas ruedas se mantengan realmente dentro de la API limitada. La versión también actualiza la generación de código de RPython. PyPy utiliza ahora saltos calculados y una expansión de código más agresiva en el código generado del intérprete. El equipo reconoce que la mejora de rendimiento no ha sido tan grande como esperaba. Ese detalle importa: el valor de esta versión no puede reducirse a un titular de benchmarks. Su trabajo más relevante está en el empaquetado, la compatibilidad y el coste de mantenimiento de otro intérprete. PyPy también ha retirado su backend interno de HPy. La nota de la versión explica que el enfoque de HPy basado en manejadores fue un prototipo útil, pero no obtuvo suficiente apoyo para convertirse en un nuevo estándar. El código de HPy permanece en el árbol de PyPy y puede activarse mediante una opción de compilación, pero ya no forma parte de la dirección predeterminada. Para quienes mantienen extensiones, la vía inmediata de compatibilidad sigue siendo la frontera existente de la API C, CFFI o la lógica de compilación específica del intérprete; no una transición amplia a HPy que elimine las decisiones anteriores. ## Por qué importa `cp312-abi3` Los paquetes de Python no se distribuyen todos de la misma manera. Un paquete escrito completamente en Python puede utilizar a menudo una rueda `py3-none-any` y ejecutarse en CPython, PyPy u otra implementación de Python 3. Un paquete que contiene código C, C++ o Rust es distinto. Su rueda puede estar vinculada a un intérprete, una ABI, un sistema operativo y una arquitectura de procesador concretos. El nombre del archivo codifica esas afirmaciones de compatibilidad. La Python Packaging User Guide describe `abi3` como la etiqueta utilizada para extensiones construidas contra la ABI estable de CPython. La ABI estable es un subconjunto restringido de la API C diseñado para seguir siendo utilizable entre distintas versiones 3 de Python. En el caso habitual, un paquete puede distribuir una rueda `cp39-abi3` por combinación de sistema operativo y arquitectura, en lugar de recompilar una extensión separada para cada versión menor de CPython. Ese beneficio no se extiende automáticamente a PyPy. Una rueda etiquetada como `cp312-abi3` hace una afirmación sobre la ABI estable de CPython. PyPy debe ofrecer una implementación compatible de la interfaz correspondiente, y las herramientas de empaquetado deben considerar la rueda durante la resolución de dependencias. La versión 8.0 de PyPy afirma que las cabeceras C y las funciones exportadas están ahora alineadas con la API limitada de CPython para Python 3.12, pero también identifica dos piezas importantes que aún faltan: el mecanismo de importación debe aceptar los objetos compartidos `abi3.so` como válidos para PyPy, y herramientas como `pip` y `uv` deben reconocer esas ruedas como candidatas. Esa distinción es el centro de la versión. Un cambio correcto en el nivel del entorno de ejecución puede aportar poco a los usuarios si el índice de paquetes, el instalador, el backend de compilación y el proyecto de la extensión no han adoptado la misma interpretación. La cadena de compatibilidad se parece, a grandes rasgos, a esto: ```text Cabeceras C y cargador de PyPy ↓ el proyecto de la extensión compila dentro de la API limitada ↓ los metadatos de la rueda anuncian una ABI compatible ↓ el instalador considera la rueda para PyPy ↓ la aplicación supera las pruebas de ejecución y comportamiento ``` Una ruptura en cualquiera de los eslabones devuelve al usuario a una compilación desde código fuente, una rueda específica de PyPy, una alternativa escrita en Python puro o un binario incompatible. PyPy 8.0 adelanta la primera parte de la cadena. No elimina la necesidad de probar las demás. ## La salvedad de compatibilidad sigue siendo importante El error más grave sería leer «compatible con ruedas abi3 de CPython 3.12» como «compatible con todos los paquetes populares de Python». Muchos paquetes no utilizan la API limitada. Pueden acceder a detalles de implementación de CPython, depender del comportamiento del recuento de referencias, asumir una disposición concreta de objetos o distribuir código generado que solo se ha probado contra CPython. Una rueda puede llevar una etiqueta aparentemente cercana a la portabilidad mientras el código interno sigue dependiendo de supuestos que PyPy no puede reproducir exactamente. PyPy ofrece desde hace tiempo una capa de compatibilidad llamada `cpyext`, que emula buena parte de la API C de CPython. Eso permite ejecutar una gran cantidad de código de extensiones, pero la emulación tiene costes. PyPy utiliza un recolector de basura basado en trazas, en lugar de la implementación de CPython basada en el recuento de referencias. Los recuentos observados mediante la capa de compatibilidad no representan necesariamente el mismo estado que vería una extensión C bajo CPython. El código que utiliza los recuentos de referencias como señal de duración, realiza tareas delicadas de liberación o depende de elementos internos específicos de CPython merece una revisión especial. La documentación de Cython señala un problema relacionado: Cython puede adaptar el código generado para PyPy, pero siguen existiendo diferencias visibles en la API C emulada. Recomienda que los autores de extensiones se apoyen, cuando sea posible, en el tratamiento generado por Cython, en lugar de utilizar directamente comportamientos de bajo nivel de la API C sin una razón clara. No es una acusación específica contra PyPy. Es un recordatorio de que una superficie estable del lenguaje y una superficie estable para extensiones nativas son problemas de ingeniería distintos. CFFI sigue siendo una alternativa importante para proyectos que necesitan admitir varias implementaciones de Python. El equipo de PyPy pide expresamente a los mantenedores de bibliotecas que utilizan extensiones C que consideren ofrecer una versión CFFI con buen rendimiento en PyPy. CFFI no vuelve portátil cualquier dependencia nativa por arte de magia, pero puede evitar algunos de los supuestos que dificultan ejecutar una extensión de CPython en otro intérprete. Los autores de extensiones Rust se enfrentan a una decisión parecida. PyO3 admite compilaciones para PyPy y ofrece configuración para detectar la implementación PyPy, pero su documentación y sus comentarios de código siguen tratando la ABI estable como una vía orientada a CPython. Por tanto, un proyecto Rust que quiera admitir CPython y PyPy debería compilar y probar explícitamente ambos destinos. No debería deducir la compatibilidad con PyPy solo porque la compilación para CPython utiliza `abi3`. ## Quién debería probar PyPy 8.0 ahora Los candidatos más claros son las aplicaciones cuyas cargas contienen bucles Python de larga duración, una cantidad importante de cálculo en Python puro o servicios que se benefician del JIT de trazas de PyPy después de que el código se caliente. El beneficio potencial resulta más creíble cuando la aplicación pasa bastante tiempo en código de nivel Python y menos tiempo esperando dentro de bibliotecas nativas que ya realizan el trabajo pesado. PyPy también es una plataforma de prueba razonable para quienes mantienen bibliotecas escritas en Python puro. Si un paquete afirma ser compatible con varias implementaciones de Python, añadir PyPy 8.0 a la matriz de CI puede revelar supuestos invisibles en las pruebas limitadas a CPython. Es especialmente útil para bibliotecas que manipulan indirectamente la duración de los objetos, utilizan mucho el despacho dinámico o prometen compatibilidad con intérpretes alternativos. La versión también interesa a los mantenedores de extensiones. Un proyecto que ya utilice Cython, CFFI o PyO3 puede emplear PyPy 8.0 para comprobar si su frontera de abstracción es realmente portable. El trabajo sobre `cp312-abi3` ofrece un objetivo concreto para la colaboración entre PyPy, los autores de extensiones y las herramientas de empaquetado. Convierte una petición amplia —«hay que mejorar el soporte de PyPy»— en una serie comprobable de problemas: ¿la extensión compila?, ¿la rueda se puede instalar?, ¿se importa correctamente?, ¿se comporta bien durante la recolección de basura y la ejecución del JIT? Los equipos que mantienen servicios Python deberían ser más selectivos. Un servicio con un árbol de dependencias moderado, pruebas de integración sólidas y una carga dominada por código Python es un candidato plausible para un piloto. Una pila de ciencia de datos con varias dependencias binarias grandes, controladores nativos de bases de datos, módulos Cython propios y ruedas específicas de proveedores es un primer objetivo mucho más arriesgado. Puede que esa pila termine funcionando, pero el beneficio previsto debe justificar el mantenimiento de otra ruta de intérprete. La razón menos convincente para probar PyPy 8.0 es que su número de versión sea mayor que el de la versión de CPython. La numeración de PyPy es la secuencia propia de versiones del proyecto; no significa que el entorno ejecute Python 8. Las versiones de lenguaje relevantes en esta entrega son Python 3.12 beta, Python 3.11 y Python 2.7. ## Un plan práctico de evaluación Una prueba sensata empieza con un inventario, no con un benchmark. Registra el archivo de bloqueo completo y clasifica cada dependencia como Python puro, extensión C, extensión Rust, biblioteca compartida externa o paquete con una ruta conocida específica de un intérprete. El resultado mostrará dónde está el trabajo real. Una lista de requisitos de primer nivel no basta, porque el paquete frágil puede estar varios niveles más abajo en el grafo de dependencias. Después, crea un entorno separado para PyPy 8.0 e instala usando el resolvedor habitual del proyecto. No preinstales una colección de ruedas de CPython suponiendo que el entorno representa la situación real. Registra qué paquetes se instalan desde ruedas, cuáles se compilan desde código fuente y cuáles son rechazados. Una instalación correcta es una evidencia útil, pero no constituye un veredicto de compatibilidad. A continuación, la suite de pruebas debería ejecutarse al menos en cuatro modos: arranque limpio, ejecución funcional breve, carga prolongada y ruta de reinicio o actualización. El modo prolongado importa porque el JIT de PyPy necesita tiempo para calentarse y porque el comportamiento del recolector de basura puede no aparecer en una ejecución corta de pruebas unitarias. Mide el tiempo de arranque, el rendimiento en régimen estable, el crecimiento de memoria, la latencia de cola y el momento en que el servicio empieza a ser útil. Un bucle interno más rápido no implica necesariamente un despliegue mejor si dominan los costes de arranque o memoria. Las fronteras nativas merecen pruebas específicas. Ejercita la serialización, los controladores de bases de datos, el procesamiento de imágenes o audio, la criptografía, la compresión, los núcleos numéricos y cualquier código que pase objetos Python a través de C o Rust. Ejecuta pruebas que fuercen la asignación y la recolección, no solo llamadas del recorrido feliz. Si la aplicación utiliza callbacks, finalizadores, protocolos de búfer o coordinación entre hilos, incluye explícitamente esas rutas. Son las zonas donde las diferencias entre intérpretes tienden a convertirse en fallos operativos y no en simples advertencias de instalación. Mantén CPython como línea base de comparación. El objetivo no es demostrar que PyPy gana en todos los benchmarks. Compara el resultado total de ingeniería: fiabilidad de compilación, comportamiento en arranque en frío, memoria, rendimiento, observabilidad, depuración, disponibilidad de ruedas y tiempo necesario para mantener sanas dos rutas de intérprete. En una carga por lotes que se ejecuta durante horas, el coste de calentamiento puede ser insignificante. En una utilidad de línea de comandos invocada cientos de veces por minuto, ese mismo coste puede borrar la ventaja. ## Los usuarios de Linux deben comprobar el límite de glibc El cambio a glibc 2.28 puede pasar desapercibido porque se presenta como infraestructura de compilación. También forma parte del contrato de distribución del entorno de ejecución. La página de descargas de PyPy indica que los binarios actuales de Linux son compatibles con manylinux 2.28 y posteriores, y señala que las compilaciones de Linux requieren glibc 2.28 o más reciente. Los usuarios de Ubuntu, Debian, Fedora y sistemas comparables actuales probablemente no encontrarán la exigencia sorprendente. Quienes mantengan distribuciones antiguas o imágenes mínimas deberían verificarla directamente. Una compilación de contenedor es el lugar más sencillo para detectar el problema. Prueba la imagen base exacta utilizada en producción, no una imagen de desarrollo más nueva. Comprueba los requisitos de bibliotecas compartidas del intérprete y ejecuta las pruebas de humo de la aplicación dentro de esa imagen. Si el despliegue apunta a una mezcla de máquinas, prueba el nodo compatible más antiguo. Un binario de PyPy que funciona en el host de compilación pero no en el host de producción más antiguo no representa una actualización exitosa. El proyecto también advierte que sus binarios de Linux incluyen OpenSSL, pero no un almacén de certificados. La documentación de descarga recomienda utilizar el almacén de certificados de la plataforma o configurar `SSL_CERT_FILE`, por ejemplo mediante el paquete `certifi`. No es un detalle exclusivo de PyPy, pero es exactamente el tipo de asunto operativo que puede perderse cuando se descarga un intérprete como archivo autónomo. Las pruebas HTTPS deberían formar parte de la validación inicial, sobre todo en herramientas que contactan con índices de paquetes, API o servicios internos. ## Descarga, verifica y aísla el experimento PyPy ofrece archivos precompilados para varias plataformas, entre ellas Linux x86-64, Linux ARM64, Windows de 64 bits y macOS tanto para Apple Silicon como para procesadores Intel. El proyecto publica sumas de comprobación para los archivos de la versión 8.0.0. Trata esas sumas como parte del proceso de instalación: descarga desde las páginas oficiales del proyecto, verifica el archivo y registra la compilación exacta del intérprete en las notas del experimento. Evita sustituir el comando `python` del sistema mientras evalúas la versión. Utiliza un entorno virtual dedicado o una ruta explícita al intérprete, conserva intacto el entorno de CPython existente y haz visible la selección en CI. Un pequeño wrapper o una entrada en la matriz resulta más fácil de retirar que un cambio de intérprete aplicado a toda la máquina y capaz de alterar silenciosamente scripts, trabajos de compilación o unidades de servicio. El proyecto afirma que compilar PyPy desde código fuente requiere mucho tiempo y recursos informáticos considerables, por lo que la mayoría de los usuarios debería empezar con los binarios oficiales. Las compilaciones desde código fuente tienen sentido para empaquetadores de distribuciones, colaboradores de PyPy o equipos que necesiten una cadena de herramientas controlada. No son la vía más corta para evaluar una aplicación normal. ## Qué implica la versión para las herramientas de empaquetado PyPy 8.0 deja al descubierto un problema de coordinación que el ecosistema de Python ha pospuesto durante años. El soporte de intérpretes suele discutirse como si fuera una propiedad exclusiva del entorno de ejecución, pero la selección de ruedas es un resultado negociado entre los metadatos del paquete, las etiquetas del instalador, los backends de compilación, la política del índice y la implementación que finalmente carga el binario. Las propias palabras del equipo de PyPy dejan claro que todavía queda trabajo en el mecanismo de importación y en herramientas como `pip` y `uv`. Eso ofrece a los mantenedores de paquetes una forma concreta de ayudar. Pueden probar la extensión del proyecto contra PyPy 3.12, revisar si realmente utiliza solo la API limitada, añadir un trabajo de PyPy en CI, publicar una rueda compatible cuando corresponda e informar de los fallos con un caso mínimo reproducible. Un usuario que abra un informe diciendo únicamente «PyPy está roto» aporta poca información. En cambio, un informe que diga «la rueda `cp312-abi3` se instala, pero falla cuando se libera un búfer después de la recolección» proporciona al ecosistema algo que puede corregir. También es un recordatorio para ser precisos en los metadatos del paquete. Una distribución de Python puro debería utilizar la etiqueta veraz más amplia. Una extensión compilada debería anunciar solo la ABI y las plataformas que realmente ha probado. Un proyecto que compila con una ABI estable pero sigue importando símbolos privados de CPython no ha conseguido la portabilidad que su nombre de archivo parece prometer. El trabajo alrededor de PyPy 8.0 solo será valioso si las afirmaciones de los paquetes se vuelven más exactas, no simplemente más optimistas. ## Alternativas y complementos CPython sigue siendo la opción predeterminada para obtener la mayor compatibilidad de paquetes, el comportamiento más predecible de las extensiones nativas y el conjunto más amplio de ruedas respaldadas por proveedores. Para muchas aplicaciones, esa es la decisión correcta. Elegir PyPy no es una declaración moral sobre la diversidad de implementaciones de Python; es una decisión sobre la carga de trabajo y el mantenimiento. Si el objetivo es reducir la fricción de las dependencias sin abandonar un entorno familiar, puede ser más útil mejorar la frontera C del paquete que cambiar de intérprete. CFFI, una API limitada bien definida, bindings generados y menos supuestos específicos de la implementación pueden mejorar la portabilidad entre CPython, PyPy y futuros entornos de ejecución. En las extensiones Rust, las compilaciones explícitas para PyPy y la compilación condicional pueden ser más fiables que esperar que un único artefacto orientado a CPython funcione en todas partes. Si el objetivo es obtener velocidad bruta, compara la aplicación real con las opciones disponibles. El JIT de PyPy puede ayudar en cargas prolongadas dominadas por Python, pero las bibliotecas nativas, la E/S, la serialización, el arranque y la memoria pueden ser los factores dominantes. Un despliegue de CPython cuidadosamente optimizado, otro algoritmo, una extensión compilada o un cambio de arquitectura de procesos pueden aportar más valor. La comparación correcta es el programa completo, no un bucle sintético. ## El veredicto PyPy 8.0 es una versión de código abierto relevante porque ataca una barrera real de adopción. El soporte beta de Python 3.12 acerca el proyecto al ecosistema actual del lenguaje. El paso a glibc 2.28 proporciona a sus binarios de Linux una base de distribución moderna. El nuevo modelo de objetos y el soporte previsto para `cp312-abi3` podrían reducir el número de paquetes que necesitan compilaciones separadas para PyPy. La salvedad es igual de importante: la compatibilidad no está completa hasta que los instaladores seleccionan las ruedas, el cargador las acepta y las aplicaciones sobreviven a cargas reales. Siguen presentes los problemas antiguos relacionados con extensiones C específicas de CPython, supuestos sobre el recuento de referencias, dependencias binarias y cobertura de pruebas desigual. PyPy 8.0 mejora el punto de partida; no hace desaparecer el grafo de dependencias. Para los desarrolladores, la recomendación práctica es probar PyPy 8.0 con una carga acotada, un archivo de bloqueo fijo y una comparación con CPython. Añádelo a CI si tu biblioteca afirma ser compatible con intérpretes alternativos. Comprueba la base de glibc, verifica las sumas del archivo descargado, prueba los certificados HTTPS e inspecciona cada dependencia nativa. Trata el soporte de Python 3.12 como beta y la compatibilidad `cp312-abi3` como un proyecto del ecosistema que todavía está en marcha. Eso basta para que la versión merezca una prueba. El argumento más sólido a favor de PyPy nunca ha sido que todos los programas Python deban cambiarse. Es que el ecosistema Python debería contar con más de una implementación seria y que elegir una de ellas debería ser posible sin convertir el empaquetado ordinario en otro proyecto de ingeniería. PyPy 8.0 acerca ese objetivo, pero el siguiente paso depende tanto de los mantenedores de bibliotecas y de las herramientas de empaquetado como del equipo del intérprete. ## Fuentes La adaptación conserva la atribución de la documentación de lanzamiento de PyPy 8.0, la documentación de descarga y sumas de comprobación de PyPy, el repositorio de PyPy, la Python Packaging User Guide, la documentación de Cython, la guía de PyO3 y la discusión de lanzamiento en Hacker News.