CPython es la implementación de referencia del lenguaje de programación Python . Escrito en C y Python, CPython es la implementación predeterminada y más utilizada del lenguaje Python.
CPython se puede definir como un intérprete y un compilador , ya que compila el código Python en bytecode antes de interpretarlo. Tiene una interfaz de funciones externas con varios lenguajes, incluido C, en la que se deben escribir explícitamente enlaces en un lenguaje distinto de Python.
Una característica particular de CPython es que hace uso de un bloqueo de intérprete global (GIL) en cada proceso de intérprete de CPython , lo que significa que dentro de un solo proceso, solo un hilo puede estar procesando código de bytes de Python en cualquier momento. [2] Esto no significa que no tenga sentido el multihilo ; el escenario de multihilo más común es donde los hilos están principalmente esperando que se completen los procesos externos.
Esto puede suceder cuando varios subprocesos atienden a clientes diferentes. Un subproceso puede estar esperando que un cliente responda y otro puede estar esperando que se ejecute una consulta a la base de datos , mientras que el tercer subproceso está procesando código Python.
Sin embargo, GIL significa que CPython no es adecuado para procesos que implementan algoritmos de uso intensivo de CPU en código Python que podrían distribuirse potencialmente entre múltiples núcleos.
En aplicaciones del mundo real, las situaciones en las que el GIL es un cuello de botella significativo son bastante raras. Esto se debe a que Python es un lenguaje inherentemente lento y, por lo general, no se utiliza para operaciones que requieren un uso intensivo de la CPU o que requieren un tiempo limitado. Python se utiliza normalmente en el nivel superior y llama a funciones en bibliotecas para realizar tareas especializadas. Estas bibliotecas, por lo general, no están escritas en Python, y el código Python en otro hilo se puede ejecutar mientras se realiza una llamada a uno de estos procesos subyacentes. La biblioteca que no es de Python a la que se llama para realizar la tarea que requiere un uso intensivo de la CPU no está sujeta al GIL y puede ejecutar simultáneamente muchos hilos en varios procesadores sin restricciones.
La concurrencia del código Python solo se puede lograr con procesos de interpretación CPython separados administrados por un sistema operativo multitarea . Esto complica la comunicación entre procesos Python concurrentes , aunque el módulo de multiprocesamiento lo mitiga un poco; significa que las aplicaciones que realmente pueden beneficiarse de la ejecución concurrente de código Python se pueden implementar con una sobrecarga limitada .
La presencia de la GIL simplifica la implementación de CPython y facilita la implementación de aplicaciones multiproceso que no se benefician de la ejecución simultánea de código Python. Sin embargo, sin una GIL, las aplicaciones multiprocesamiento deben asegurarse de que todo el código común sea seguro para subprocesos.
Aunque se han hecho muchas propuestas para eliminar el GIL, el consenso general ha sido que, en la mayoría de los casos, las ventajas del GIL superan las desventajas; en los pocos casos en los que el GIL es un cuello de botella, la aplicación debe construirse en torno a la estructura de multiprocesamiento. Para ayudar a permitir un mayor paralelismo, se lanzó una mejora en octubre de 2023 para permitir un GIL separado por subintérprete en un solo proceso de Python y se han descrito como "hilos con uso compartido opcional". [3] [4]
Después de varios debates, en 2023 se lanzó un proyecto para proponer que el GIL sea opcional a partir de la versión 3.13 de Python, [5] cuyo lanzamiento está previsto para octubre de 2024. [6]
Unladen Swallow era una rama de optimización de CPython, pensada para ser totalmente compatible y significativamente más rápida. Su objetivo era lograr sus objetivos complementando la máquina virtual personalizada de CPython con un compilador en tiempo real creado con LLVM .
El proyecto había establecido como objetivo mejorar la velocidad en un factor de cinco con respecto a CPython; [7] este objetivo no se cumplió. [8]
El proyecto fue patrocinado por Google , y los propietarios del proyecto, Thomas Wouters, Jeffrey Yasskin y Collin Winter, son empleados de Google a tiempo completo; sin embargo, la mayoría de los contribuyentes al proyecto no eran empleados de Google. [9] Unladen Swallow fue alojado en Google Code . [10]
Al igual que muchas cosas relacionadas con el lenguaje Python, el nombre Unladen Swallow es una referencia a Monty Python , específicamente al chiste sobre la velocidad del aire de las golondrinas sin carga en Monty Python y el Santo Grial .
Aunque no alcanzó todos los objetivos publicados, Unladen Swallow produjo algo de código que se agregó a la implementación principal de Python, como mejoras en el módulo cPickle. [11]
En julio de 2010, algunos observadores especularon sobre si el proyecto estaba muerto o moribundo, ya que el hito del cuarto trimestre de 2009 aún no se había publicado. [12] El tráfico en la lista de correo de Unladen había disminuido de 500 mensajes en enero de 2010 a menos de 10 en septiembre de 2010. [13] También se ha informado de que Unladen perdió la financiación de Google. [14] En noviembre de 2010, uno de los principales desarrolladores anunció que "Jeffrey y yo hemos sido arrastrados a otros proyectos de mayor importancia para Google". [15]
La rama de desarrollo del cuarto trimestre de 2009 se creó el 26 de enero de 2010, [16] pero no se hizo publicidad en el sitio web. Además, en relación con los planes a largo plazo, y como el proyecto no logró el lanzamiento de Python 2.7, se aceptó una propuesta de mejora de Python (PEP) [8] , que proponía una fusión de Unladen Swallow en una rama especial py3k-jit del repositorio oficial de Python . A julio de 2010, este trabajo estaba en curso. [17] Esta fusión habría llevado algún tiempo, ya que Unladen Swallow se basó originalmente en Python 2.6 [18] con el que Python 3 rompió la compatibilidad (consulte Python 3000 para obtener más detalles). Sin embargo, la PEP se retiró posteriormente.
A principios de 2011, quedó claro que el proyecto estaba detenido. [19]
Las plataformas de nivel 1 con soporte oficial son Linux para Intel de 64 bits que utiliza una cadena de herramientas GCC, macOS para Intel y ARM de 64 bits, y Microsoft Windows para Intel de 32 y 64 bits. Existe soporte oficial de nivel 2 para Linux para ARM de 64 bits, wasm32 ( Web Assembly ) con soporte de entorno de ejecución WASI y Linux para Intel de 64 bits que utiliza una cadena de herramientas clang. Los sistemas de nivel 3 con soporte oficial incluyen ARM Windows de 64 bits, iOS de 64 bits, Raspberry Pi OS (Linux para armv7 con punto flotante duro), Linux para PowerPC de 64 bits en modo little-endian y Linux para s390x .
Más plataformas tienen implementaciones funcionales, entre ellas: [23]
PEP 11 [24] enumera las plataformas que no son compatibles con CPython según la Python Software Foundation . Estas plataformas aún pueden ser compatibles con puertos externos. Estos puertos incluyen:
Los puertos externos no integrados a la versión oficial de CPython de Python Software Foundation, con enlaces a su sitio de desarrollo principal, a menudo incluyen módulos adicionales para funcionalidades específicas de la plataforma, como API de gráficos y sonido para PSP y SMS y API de cámara para S60. Estos puertos incluyen:
Estas versiones de Python se distribuyen con las distribuciones de Linux empresariales compatibles actualmente. [33] El estado de soporte de Python en la tabla se refiere al soporte del equipo central de Python y no del mantenedor de la distribución.
CPython es una de las varias implementaciones de Python con "calidad de producción", entre las que se incluyen: Jython , escrita en Java para la máquina virtual Java (JVM); PyPy , escrita en RPython y traducida a C; y IronPython , escrita en C# para la Common Language Infrastructure . También existen varias implementaciones experimentales. [55]
{{cite web}}: Falta o está vacío |title=( ayuda )