[Python-es] (Iron)Python en Visual Studio 2008

Chema Cortes pych3m4 en gmail.com
Mar Ene 19 20:28:38 CET 2010


El día 19 de enero de 2010 17:56, Vicent <vginer en gmail.com> escribió:
> Aprovecho el cambio de alojamiento de la lista para plantear unas dudas
> sobre IronPython.

Voy a intentar responder la parte del mensaje que no te ha respondido Hernan.

> Por otro lado, se suele decir que el código C/C++ se ejecuta más rápido que
> el Python porque el primero es compliado y el segundo es interpretado.
> Mi primera duda es genérica, y está relacionada con la afirmación anterior:
> si al final creamos un ejecutable a partir de código escrito en Python, ¿no
> es ya algo compilado y que va a correr "suficientemente rápido"? Esto nunca
> lo he acabado de entender, porque no conozco a fondo la teoría que hay
> detrás; "funciono" a base de intuición.

Ahora mismo no se diferencian los lenguajes en interpretados o
compilados. Por ejemplo, el código java se "compila" a bytecode,
bytecode que se "interpreta" por la máquina virtual JVMk, que ejecuta
instrucciones de código máquina que. luego la CPU pasa por un
"microintérprete" para descomponer microinstrucciones que se procesan
en paralelo con lógica predictiva...

Si lo analizas bien, resulta que en todo el proceso se ha pasado de
intérprete a compilado y viceversa varias veces. La verdadera
distinción está entre lenguaje "estático" y "dinámico". En el estático
sería el que necesita conocer previamente todo el camino de ejecución
del programa, así como los recursos que se van a emplear. El
compilador (por llamarlo de alguna manera) analiza el código y lo
optimizará según los requisitos (velocidad, gasto de memoria, etc). En
los lenguajes dinámicos, no puedes estar seguro por dónde irá la
ejecución, ni tan siquiera cuándo se crean o destruyen los objetos.

Lo habitual es que los lenguajes dinámicos vayan aprendiendo mientras
van ejecutando el código. El python estándar crea ficheros .pyc con el
bytecode compilado que reusa durante la ejecución; pero sería posible
añadir otros optimizadores que compilen, en tiempo de ejecución
("Just-in-Time compilers"), para generar un código máquina muy similar
al que crearían compiladores estáticos (pe: python-psyco). Al compilar
en tiempo de ejecución, el compilador JIT puede centrarse en aquella
parte del programa que más necesita optimizarse, algo que es difícil
deducir con un análisis previo. De momento no se consigue el mismo
nivel de optimización; pero si consideras, por ejemplo, que Ironpython
usa como bytecode el mismo que usa C#, hay entusiastas que dicen que
será posible que ironpython alcance a C# en velocidad. De momento lo
han conseguido con algunos algoritmos determinados.

Pero si realmente quieres entender la técnica que hay detrás, te
aconsejo que revises PyPy. La idea subyacente es la crear un framework
para lenguajes dinámicos que separía la parte estática (de bajo nivel)
del intérprete propiamente dicho, con lo que se espera optimizar mucho
los compiladores JIT empleados en los lenguajes dinámicos. Aquí
también hay optimistas que dicen que habrá lenguajes dinámicos más
rápidos que el C.

  http://codespeak.net/pypy/dist/pypy/doc/index.html

> me preguntaba si podría
> "pasar del C" y "pasarme a Python" sin perder "nada". Dejando de lado que he
> encontrado unas librerías externas en C que me hacen falta y que no sé
> todavía si estarían en Python,

Nunca deberías hacer una transición así por completo. Lo mejor es
combinar ambos mundos. Python puede utilizar librerías C gracias al
módulo ctype, con lo que puedes usarlas sin necesidad de un binding en
python. Puedes emplear python para prototipar tus aplicaciones y
dotarlas de un interface gráfico, y emplear C para crear módulos o
para optimizar aquellas partes del programa que veas peor en python.

> ¿podría generar ejecutables igual de rápidos,
> eficientes, etc. que ahora mismo con C++ si usase IronPython en Visual
> Studio 2008? Además, por lo que entiendo, Visual Studio te facilita bastante
> la vida con todo el tema de las ventanitas, etc., de cara a crear una
> interfaz gráfica. ¿O no?
> Incluso, entiendo que no tendría por qué "pasar del C", y que dentro de
> Visual Studio incluso quizás pueda ser más fácil la integración de las
> librerías escritas en C que comentaba arriba en mi código Python. ¿No?

La idea detrás de .Net es que la aplicación sea independiente del
lenguaje que hayas usado en cada una de sus partes. No puedo
asegurarte mucho más. Lo único es que tengas presente es que
ironpython lo tendrás que combinar con C#. Para usar C tendrás que
usar python (CPython), que no está para Visual Studio.



Más información sobre la lista de distribución Python-es