Python es asombroso.
Sorprendentemente, esa es una declaración bastante ambigua. ¿A quĆ© me refiero con ‘Python’?, ¿Me refiero a la interfaz abstracta de Python?, ¿Me refiero a CPython, la implementación comĆŗn de Python (y no confundir con Cython, que son similares en sus nombres)?, ¿O me refiero a algo completamente distinto? Tal vez me estĆ© refiriendo indirectamente a Jython, o IronPython, o PyPy. O tal vez me he ido al extremo y estoy hablando de RPython o RubyPython (los cuales son cosas muy, muy distintas).
Mientras las tecnologĆas mencionadas anteriormente son llamadas de formas parecidas y referenciadas de la misma manera, algunas de ellas sirven para propósitos completamente distintos (o, al menos, operan de maneras completamente distintas).
A lo largo de mi tiempo trabajando con Python, me topé con toneladas de estas herramientas .*ython. Pero no hasta hace poco me tomé el tiempo de entender qué es lo que son, cómo funcionan y por qué son necesarias (a sus maneras).
En este artĆculo, voy a empezar desde cero y recorrerĆ© varias implementaciones de Python, concluyendo con una introducción detallada a PyPy, el cual creo es el futuro del lenguaje.
Todo empieza con entender que es lo que ‘Python’ realmente es.
Si tienes un buen entendimiento sobre código binario, mÔquinas virtuales y parecidos, siéntete libre de saltarte esta parte.
“Python es interpretado o compilado?”
Este es un punto común de confusión para principiantes en Python.
La primera cosa que hay que saber es que ‘Python’ es una interfaz. Existe una
especificación sobre lo que Python deberĆa hacer y cómo
deberĆa comportarse (cómo con cualquier interfaz). Y hay mĆŗltiples implementaciones (como en cualquier interfaz).
Lo segundo que hay que saber es que ‘interpretado’ y ‘compilado’ son propiedades de una implementación, no de una interfaz.
Entonces, la pregunta no estĆ” realmente bien formada.
¿Python es interpretado o compilado? La pregunta no estĆ” realmente bien formada.
Dicho esto, para la implementación mĆ”s comĆŗn (CPython: escrito en C, usualmente llamado simplemente ‘Python’, y seguramente lo que estĆ”s usando si no tienes idea de lo que estoy hablando), la respuesta es:interpretado, con algunas partes compiladas. CPython compila** el código fuente de Python a *bytecode, y en ese momento interpreta ese bytecode, ejecutĆ”ndolo sobre la marcha.
* Nota: no es una ‘compilación’ en sentido tradicional de la palabra. Normalmente, decimos que ‘compilar’ es tomar el código de alto nivel y convertirlo en código binario. Pero es un tipo de ‘compilación’.
Veamos la respuesta un poco mĆ”s de cerca, ya que nos permitirĆ” entender algunos de los conceptos que surgirĆ”n mĆ”s adelante en el artĆculo.
Bytecode vs. código binario
Es muy importante entender la diferencia entre bytecode y código binario (o nativo), tal vez mejor ilustrada con ejemplos:
- C compila a código binario, que luego es ejecutado directamente en tu procesador. Cada instrucción le indica a tu CPU que mueva cosas alrededor.
- Java compila a bytecode, que luego es ejecutado en la mÔquina virtual de Java(Java Virtual Machine, ó JVM), una abstracción de una computadora que ejecuta programas. Cada instrucción es entonces manejada por la JVM, que interactúa con tu computadora.
En términos breves: código binario es mÔs rÔpido, pero bytecode es mÔs portable y seguro.
El código binario se ve distinto, dependiendo de tu mĆ”quina, pero bytecode se ve igual en todas las maquinas. Se podrĆa decir que el código binario estĆ” optimizado para tu configuracion.
Volviendo a CPython, el proceso en el conjunto de herramientas sucede de la siguiente manera:
- CPython compila tu código Python a bytecode
- Ese bytecode es entonces ejecutado en la MƔquina Virtual CPython
Los principiantes asumen que Python es compilado a raĆz de los archivos .pyc. Hay alguna verdad en esto: el archivo .pyc es bytecode compilado, que es despuĆ©s interpretado. Entonces si haz ejecutado código Python y ya tienes un archivo .pyc disponible, el mismo va a ejecutarse mĆ”s rĆ”pido la segunda vez ya que no necesitarĆ” recompilar el bytecode.
Maquinas virtuales alternativas: Jython, IronPython, y mƔs
Cómo mencionĆ© anteriormente, Python tiene varias implementaciones. De vuelta, como mencionĆ© antes, la mĆ”s comĆŗn es CPython. Ćsta es una implementación de Python escrita en C y es considerada la implementación ‘por defecto’.
¿Pero, quĆ© pasa con las alternativas? Una de las mĆ”s prominentes es
Jython, una implementación en Java que utiliza la JVM. Mientras CPython produce bytecode para ser corrido en la VM de CPython, Jython produce
bytecode de Java para correr en la JVM (esto es lo mismo que es producido cuando se compila un programa en Java).
“¿Por quĆ© usarĆa alguna vez una implementación alternativa?”, podrĆas preguntar. Bueno, para empezar, esasdiferentes implementaciones juegan muy bien con diferentes conjuntos de tecnologĆas.
CPython hace muy fÔcil el escribir extensiones C para tu código Python porque al final es ejecutado por un intérprete de C. Por otro lado, Jython, facilita trabajar con otros programas en Java: puedes importar cualquier clase de Java sin mayor esfuerzo, evocando y utilizando tus clases Java dentro tus programas Jython.
(Nota aparte: si no pensaste en esto detalladamente, es una locura. Estamos en un punto donde puedes mezclar y triturar diferentes lenguajes y compilarlos todos en una misma esencia. Como fue mencionado por Rostin, los programas que mezclan código Fortran y C estÔn desde hace un tiempo. Asà que, por supuesto que esto no es algo necesariamente nuevo. Pero sigue siendo genial.)
Cómo ejemplo, esto es código Jython vÔlido:
[Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_51
>>> from java.util import HashSet
>>> s = HashSet(5)
>>> s.add("Foo")
>>> s.add("Bar")
>>> s
[Foo, Bar]
IronPython es otra implementación popular de Python, escrita enteramente en C# y apuntando a la tecnologĆa .NET. En particular, corre con lo que se podrĆa llamar la MĆ”quina Virtual .NET,
Common Language Runtime (CLR)de Microsoft, comparable con la JVM.
PodrĆas decir que Jython : Java :: IronPython : C#. Corren en sus respectivas VMs, puedes importar clases C# en tu código IronPython y clases Java desde tu código Jython, etc.
Es totalmente posible sobrevivir sin tocar alguna vez una implementación de Python no-CPython. Pero hay ventajas que se obtienen desde el cambio, muchas de ellas son dependientes de la tecnologĆa que uses. ¿Usas muchos lenguajes basados en la JVM? Jython puede ser para tĆ. ¿Todo lo que haces es sobre la tecnologĆa .NET? Tal vez debas probar IronPython (y tal vez ya lo hayas hecho).

Por cierto: mientras que esto no serĆa una razón para usar una implementación diferente, nota que estas implementaciones sĆ difieren en comportamiento mĆ”s allĆ” de como tratan tu código fuente en Python. Sin embargo, esas diferencias son comĆŗnmente menores, y se disuelven o emergen con el tiempo mientras estas implementaciones se encuentran bajo un activo desarrollo. Por ejemplo, IronPython
usa cadenas Unicode por defecto; Sin embargo, CPython,
por defecto usa ASCII para versiones 2.x (fallando con un error de codificación
UnicodeEncodeError para caracteres no-ASCII), pero sĆ soporta cadenas
Unicode por defecto para las versiones 3.x.
Compilación Justo-a-Tiempo: PyPy y el futuro
Por lo tanto, tenemos una implementación de Python escrita en C, una en Java una en C#. El próximo paso lógico: una implementación de Python escrita en… Python. (El lector educado encontrarĆ” esta notación levemente engaƱosa).
Aquà es donde las cosas se ponen confusas. Primero, discutamos sobre compilación Justo-a-Tiempo (Just-in-Time, ó JIT).
JIT: El por qué y el cómo
Recordemos que el código binario es mucho mĆ”s rĆ”pido que bytecode. Bueno, ¿y si pudiĆ©ramos compilar algunas partes de nuestro bytecode y luego correrlo como código nativo? TendrĆamos que pagar algĆŗn precio al compilar a bytecode (por ej., tiempo), pero si el resultado fuese mĆ”s rĆ”pido, eso serĆa genial! Esa es la motivación de la compilación JIT, una tĆ©cnica hĆbrida que mezcla los beneficios de los interpretadores y los compiladores. En tĆ©rminos bĆ”sicos, JIT quiere utilizar compilación para acelerar un sistema interpretado.
Por ejemplo, un enfoque común tomado por la compilación JIT:
- Identificar bytecode que es ejecutado frecuentemente.
- Compilar a código binario.
- Almacenar el resultado en memoria cachƩ.
- Siempre que el mismo bytecode sea encontrado para ejecutar, en vez de usarlo, ejecutar el código binario precompilado y cosechar los beneficios (por ej., aumentos de velocidad)
De esto se trata PyPy: llevar JIT a Python (mira el ApĆ©ndice para ver esfuerzos anteriores). Hay, por supuesto, otros objetivos: PyPy apunta a ser multiplataforma, bajo en consumo de memoria e independiente del conjunto de tecnologĆas. Pero JIT realmente se vende por si solo. Como promedio de un puƱado de pruebas de tiempo, se dice que mejora el rendimiento a un factor de
6.27. Para un mayor anƔlisis, vƩase este cuadro del
PyPy Speed Center:
PyPy es difĆcil de entender
Pero hay mucha confusión alrededor de PyPy (véase, por ejemplo, esta propuesta sin sentido para crear un
PyPyPy…). En mi opinión, eso es principalmente porque PyPy es actualmente dos cosas:
Un intƩrprete de Python escrito en
RPython (no Python (he mentido antes). RPython es un subconjunto de Python con tipos estĆ”ticos. En Python, es “
prĆ”cticamente imposible” razonar rigurosamente acerca de tipos (¿Por que es tan difĆcil? Bueno, considera el hecho que:
x = random.choice([1, "foo"])
serĆa código Python vĆ”lido (crĆ©ditos a
Ademan). ¿De quĆ© tipo es x? ¿Cómo podemos razonar acerca de tipos de variables cuando los tipos ni siquiera son estrictamente forzados?). Con RPython, sacrificas algo de flexibilidad, pero a cambio es muchĆsimo mĆ”s fĆ”cil razonar sobre manejo de memoria y demĆ”s, lo cual permite optimizaciones.
Un compilador que compila código RPython para varios objetivos y agrega JIT. La plataforma por defecto es C, por ej., un compilador RPython-a-C, pero también puedes apuntar a JVM y otros.
Ćnicamente para mayor claridad, me referirĆ© a ellos como PyPy (1) y PyPy (2).
¿Por quĆ© necesitarĆas esas dos cosas, y por quĆ© bajo el mismo techo? PiĆ©nsalo de esta manera: PyPy(1) es un intĆ©rprete escrito en RPython. Entonces toma el código Python del usuario y lo compila a bytecode. Pero el interpretador en sĆ (escrito en RPython) tiene que ser interpretado por otra implementación de Python para poder correr, ¿Verdad?
Bueno, podrĆamos simplemente
usar CPython para correr el intĆ©rprete. Pero eso no serĆa lo suficientemente rĆ”pido.
En cambio, la idea es que usemos PyPy(2) (también conocido cómo RPython Toolchain)-Set de herramientas RPython) para compilar al interpretador de PyPy a código que otra plataforma (por ej., C, JVM o CLI) pueda correr en nuestra mÔquina, agregando también JIT. Es mÔgico: PyPy agrega dinÔmicamente JIT a un interpretador, generando su propio compilador! (De vuelta, esto es una locura: estamos compilando un interpretador y agregando otro compilador independiente por separado).
Al final, el resultado es un ejecutable independiente que interpreta el código fuente Python y explota las optimizaciones de JIT. Que es lo que justamente querĆamos! Es un gran bocado, pero tal vez este diagrama ayude:
Reiterando, la verdadera belleza de PyPy es que podemos escribir nosotros mismos un puƱado de interpretadores Python distintos en RPython sin preocuparnos por JIT (salvo algunas sugerencias). PyPy entonces implementarĆa JIT por nosotros usando el set de herramientas de RPython/PyPy(2).
De hecho, si nos ponemos aĆŗn mĆ”s abstractos, podrĆas, teóricamente, escribir un interpretador para cualquierlenguaje, alimentar a PyPy con Ć©l, y obtener un JIT para ese lenguaje. Esto es porque PyPy se enfoca en optimizar el interpretador actual, en vez de los detalles del lenguaje que estĆ” interpretando.
PodrĆas, teóricamente, escribir un interpretador para *cualquier* lenguaje, alimentar a PyPy con Ć©l, y obtener un JIT para ese lenguaje.
Divagando un poco, me gustarĆa mencionar que JIT en sĆ mismo es absolutamente fascinante. Usa una tĆ©cnica llamada tracing (ó seguimiento), la cual se ejecuta
de la siguiente manera:
- Correr el interpretador e interpretar todo (sin agregar nada de JIT)
- Perfilar levemente el código interpretado.
- Identificar operaciones que hayas realizado antes.
- Compilar esos pedazos a código binario.
Para mÔs información, este documento es altamente accesible y muy interesante.
Para ir concluyendo: usamos el compilador RPython-a-C de PyPy (u otra plataforma) para compilar el interpretador implementado RPython de PyPy.
Concluyendo
¿Por quĆ© es tan genial? ¿Por quĆ© vale la pena perseguir esta idea tan loca? Creo que
Alex Gaynor lo describió muy bien en su
blog: “[PyPy es el futuro] porque ofrece mejor velocidad, mĆ”s flexibilidad y es una mejor plataforma para el crecimiento de Python.”
En resumen:
ApĆ©ndice: Otros nombres que tal vez hayas oĆdo
- Python 3000 (Py3k): nombre alternativo para Python 3.0, un mayor, compatible-con-versiones-anterioreslanzamiento de Python que alcanzó la escena en 2008. El equipo de Py3k predijo que llevarĆa alrededor decinco anos para que esta versión sea completamente adoptada. Y mientras que la mayorĆa (cuidado: se dice que es anecdótico) de los desarrolladores de Python siguen usando Python 2.x, la conciencia de Py3k entre la gente estĆ” incrementĆ”ndose.
- Cython: un super set de Python que incluye bindings (ó enlaces)para llamar funciones de C.
- Objetivo: permitirte escribir extensiones en C para tu código Python
- AdemÔs te permite agregar tipos de variables estÔticos a tu código Python, permitiéndole que sea compilado y alcanzar rendimiento parecido al de C.
- Es similar a PyPy, pero no es lo mismo. En este caso, estÔs forzado a escribir el código del usuario antes de pasarlo al compilador. Con PyPy, escribes simplemente código Python, y el compilador maneja cualquier optimización.
- Numba: : un “compilador especializado justo-a-tiempo” que agrega JIT a código Python anotado. En tĆ©rminos mĆ”s bĆ”sicos, le das algunas indicaciones y acelera partes de tu código. Numa viene como parte de la distribución Anaconda,un set de paquetes para manejo y anĆ”lisis de datos.
- IPython: muy diferente a todo lo que hemos discutido hasta ahora. Es un ambiente de procesamiento para Python. Interactivo y con soporte para herramientas grƔficas y experiencia de navegador, etc.
Enlaces de lenguaje
- RubyPython: un puente entre las mÔquinas virtuales de Ruby y Python. Permite embeber código de Python dentro de tu código de Ruby. Defines donde Python comienza y termina, y RubyPython calcula los datos entre las VMs.
- PyObjc: enlaces de lenguaje entre Python y Objetive-C, actuando como un puente entre ellos. PrĆ”cticamente, eso significa que puedes utilizar librerĆas de Objective-C (incluyendo todo lo que necesitas para crear aplicaciones de OS X) desde tu código Python, y módulos de Python desde tu código Objective-C. En este caso, es conveniente que CPython estĆ© escrito en C, el cual es un subconjunto de Objective-C.
- PyQt: mientras PyObjc te ofrece una interfaz para los componentes grƔficos de OS X, PyQt hace lo mismo para el framework de QT, permitiendote crear completas interfaces grƔficas, acceso a bases de datos SQL, etc. Otra herramienta dirigida a traer la simplicidad de Python a otros frameworks.
Frameworks JavaScript
- pyjs (Pyjamas): un framework para crear aplicaciones web y de escritorio en Python. Incluye un compilador Python-a-Javascript, un conjunto de widgets, y algunas herramientas mƔs.
- Brython: una mÔquina virtual de Python escrita en JavaScript para permitir que el código de Py3k sea ejecutado en navegadores.
Creditos:
Fuente Original: