[pyar] ¿Existe algo asi como un "compilador" Python?

[Daniel]

Es casi casi un artículo de la PET :)


El 24 de abril de 2014, 18:36, fisa <fisadev en gmail.com> escribió:

> El día 24 de abril de 2014, 12:12, Ariel Palazzesi
> <arielpalazzesi en gmail.com> escribió:
> > Hola!
> > Como saben, recien estoy empezando a hacer algunas cosas en Python,
> > generalmente tonterias para ejecutar desde la consola de Linux.
> >
> > Veo que hay aplicaciones enormes y complejas hechas con este lenguaje, y
> me
> > pregunto ¿Hay algun compilador para el?  O siempre se interpreta?
> >
> > Saludos, y perdón por la preguntonta.
> >
>
> Buenas! Después de ver el thread, me parece que suma que me tome el
> trabajo de armar una respuesta bien completa.
> Va a ser larga, pero probablemente te sepa para conocer un poco mejor
> algunas cosas útiles.
> Y voy a ir diciendo cosas no tan correctas, y de a poco corrigiéndome
> a medida que avanzo. Pero bienvenidas las lecturas de los que saben
> más como para indicarme si le erro feo en algo.
>
> Tradicionalmente en la univ te enseñan que hay dos tipos de lenguajes:
> compilados e interpretados. Y la explicación de cómo funciona cada uno
> es algo que se parece a esto:
>
> Lenguaje compilado:
> 1) Escribo código.
> 2) Una sola vez (y eso es importante) lo *compilo*, con un compilador,
> y eso me genera un binario.
> 3) El binario es ejecutado todas las veces que quiero usar el programa.
>
> Lenguaje interpretado:
> 1) Escribo código.
> 2) *Cada vez que ejecuto mi programa* (y eso es importante) un
> intérprete genera instrucciones binarias y las ejecuta a partir de
> leer mi código.
>
> En esta explicación hay algunas cosas que no quedan muy claras. Por
> ejemplo: qué es "binario"? No existe tal cosa como un código de
> instrucciones en binario que sea universal y que se ejecute
> directamente sobre cualquier procesador. Hay varias arquitecturas, y
> normalmente uno no va directo al micro, sino que interactúa con cosas
> que están en el medio (especialmente el sistema operativo). Pero
> bueno, por ahora dejamos esas cosas de lado, no son las que más me
> interesan.
> Para los ejemplos voy a seguir hablando de "binarios" como lo que
> "finalmente se ejecuta en el procesador", sin tener en cuenta si en
> realidad hay alguna capa intermedia del sistema operativo y demás.
>
> Primer cosa que sí interesa: el límite entre esos dos tipos de
> lenguajes ya es borroso.
> Por ejemplo, qué pasa si mi intérprete guarda las instrucciones
> binarias generadas en alguna especie de caché, y las reutiliza la
> próxima vez que ejecuto mi programa? No sería casi lo mismo que un
> compilador? Porque hace la traducción una sola vez, y después ejecuta
> esos binarios.
> Es buena pregunta para hacerle al profe ;)
>
> Pero se pone un poco más interesante cuando miramos a lo que hacen
> lenguajes más nuevos como java, python, c#, ruby, etc.
>
> Agarremos primero java y C#. De qué tipo son? La mayoría seguro
> respondería que son compilados. Pero en realidad no tienen esos 3
> pasos que vimos antes, sino que hacen algo parecido, algo como esto:
> 1) Escribo código.
> 2) *Una sola vez* lo compilo, con un compilador, pero no a binario!
> Compilo a un archivo con código "intermedio", parecido al binario,
> pero de un cachito más alto nivel.
> 3) *Cada vez que ejecuto mi programa*, la máquina virtual o runtime
> del lenguaje, va leyendo ese código intermedio, generando
> instrucciones binarias y las ejecuta.
>
> Es eso un lenguaje compilado o un lenguaje interpretado? Tiene un poco
> de cada cosa: compila a un lenguaje intermedio, que después
> interpreta.
> Ese lenguaje intermedio es "casi" un binario, eso seguro, y por eso la
> mayoría te va a decir que son lenguajes compilados. Pero no se puede
> negar que necesita del runtime para poder ejecutar (traducir) ese
> intermedio a un binario de verdad, algo que es prácticamente un
> intérprete (lee un lenguaje, genera binario, en tiempo de ejecución).
>
> Y python qué hace?
> Hace casi casi casi lo mismo! con una sola diferencia:
> En java o C# el desarrollador hace el paso 2 como un paso específico.
> En tu IDE hacés click en "compilar", o algo similar.
> En Python ese paso se hace solo (automágicamente) la primera vez que
> intentás ejecutar tu código.
>
> Tanto en java como en python tenemos esa compilación a código
> intermedio que sucede una sola vez, y luego la interpretación de ese
> pre-compilado usando un runtime.
> La diferencia está en que en java vos tenés que hacer el primer paso
> manualmente, y en python se hace solo en la primer ejecución.
>
> Y si lo pienso un poco, estoy casi seguro que la gente le dice
> "compilado" a java o c# solamente porque tienen que hacer ese paso a
> mano, si se lo hiciese solo el runtime al ejecutar la primera vez, no
> se si les dirían "compilados".
>
> Y ahora a complicarla un poco más:
>
> Hay una sola forma de ejecutar python?
> No, hay varias, ya te comentaron que hay unos cuantos "compiladores" de
> python.
> Cuando la gente habla de python por lo general se refiere al
> intérprete oficial, que es CPython (no confundir con Cython). Lo que
> yo expliqué hasta recién es el comportamiento de *ese* intérprete.
>
> Y el resto hacen lo mismo? O sea, tienen los mismos pasos de los que
> hablábamos recién?
> Nop. Por ejemplo PyPy hace algo más complicado (que no voy a explicar
> acá). Jython o IronPython también tienen sus diferencias. Etc.
> Así que si ya era complicado decidir si python era "compilado" o
> "interpretado", imaginate ahora sabiendo que hay muchas formas
> distintas de ejecutarlo.
>
> Y para cerrar, algunas ideas sueltas más referidas al tema de
> velocidad, que era el origen de tu pregunta.
>
> * Estas diferencias en modo de ejecutar por lo general no son las que
> van a hacer que tu programa sea más rápido o lento. El tema está más
> del lado de qué tan bueno o qué cosas optimiza el runtime, y no
> depende del momento en que hagas la compilación al intermedio. Por
> ejemplo, PyPy hace cosas muy interesantes para que el runtime ejecute
> algunas cosas *mucho* más rápido que el intérprete oficial.
>
> * El tamaño de un programa tampoco es para nada un indicador de si va
> a ser lento o no. La velocidad es una cosa que depende más de la
> calidad y cosas que hace el código, y muy poco de que cuánto código
> es. Así que no te guíes con esa regla de que si es un sistema
> "grande", necesita un intérprete más rápido, porque el tamaño no es
> buena medida. Por ejemplo: un script muy chico de 50 lineas que haga
> algo de machine learning puede ser terriblemente más pesado en uso de
> cpu que un sistema de gestión de 300.000 lineas.
>
> * Y la velocidad de ejecución del código en sí tampoco suele ser un
> factor determinante en la velocidad de ese tipo de sistemas, donde la
> mayor parte del tiempo se consume en esperas de red, IO, etc
> (interacciones con la base de datos, con otros sistemas,...). Así que
> en tanto no vas que específicamente el código de algo sea lo lento, y
> no disco, red, etc, ni vale la pena ponerse a optimizar el código. La
> mayoría de las veces podés sacar mucha más ganancia con cosas como que
> la db use más ram, o meter algún tipo de caché.
>
>
> Saludos!
>
> --
> fisa  -  Juan Pedro Fisanotti
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>



-- 
Daniel Malisani
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140424/6d053a9e/attachment-0001.html>