Discussion:
¿Existe algo asi como un "compilador" Python?
(too old to reply)
Ariel Palazzesi
2014-04-24 15:12:57 UTC
Permalink
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.

--------------------------------------------------------------------------------------------------------------------------
Ariel Palazzesi

*“Si cualquier habilidad que aprende un niño será obsoleta antes de que la
use, entonces, ¿qué es lo que tiene que aprender? La respuesta es obvia: La
única habilidad competitiva a largo plazo es la habilidad para
aprender“.*Seymour Papert
Gabriel Acosta
2014-04-24 15:21:30 UTC
Permalink
Python es un lenguaje interpretado, un código python no necesita ser compilado, necesita de un intérprete que hace mas o menos algo asi como 'compilar' pero no se genera un ejecutable. A qué te refieres con programas grandes ?

Saludos.
-----Mensaje original-----
De: Ariel Palazzesi
Enviado: 24/04/2014, 12:12
Para: Python Argentina
Asunto: [pyar] ¿Existe algo asi como un "compilador" Python?


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.

--------------------------------------------------------------------------------------------------------------------------
Ariel Palazzesi

*“Si cualquier habilidad que aprende un niño será obsoleta antes de que la
use, entonces, ¿qué es lo que tiene que aprender? La respuesta es obvia: La
única habilidad competitiva a largo plazo es la habilidad para
aprender“.*Seymour Papert

_______________________________________________
pyar mailing list ***@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 Softwar
Roberto Alsina
2014-04-24 15:24:52 UTC
Permalink
On 24/04/14 12:21, Gabriel Acosta wrote:
> Python es un lenguaje interpretado, un código python no necesita ser compilado, necesita de un intérprete que hace mas o menos algo asi como 'compilar' pero no se genera un ejecutable. A qué te refieres con programas grandes ?

Python es un lenguaje que tiene un montón de implementaciones. Unas
cuantas de esas son compiladas, incluyendo, pero no limitadas a:

Nuitka, Jython, IronPython, PyPy, Shedskin.
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Juan Carlos
2014-04-24 15:41:39 UTC
Permalink
2014-04-24 12:24 GMT-03:00 Roberto Alsina <ralsina-***@public.gmane.org>:

> Python es un lenguaje que tiene un montón de implementaciones. Unas
> cuantas de esas son compiladas, incluyendo, pero no limitadas a:
>
> Nuitka



https://www.youtube.com/watch?v=wsczq6j3_bA#t=1426
Ariel Palazzesi
2014-04-24 16:00:32 UTC
Permalink
Hola!

Espectaculares las respuestas. Ya tengo otro montón de cosas para leer :)

Con "grandes" me refiero a aplicaciones para la gestión de comercios o
cosas asi, con decenas o cientos de archivos .py, etc. Yo lo vehia casi
como un lenguaje para hacer pequeños scripts.

Al ver que se utiliza en esos entornos, me surgio la duda de la compilacion
para optimizar la velocidad de ejecución y para proteger el código fuente.

Saludos!

--------------------------------------------------------------------------------------------------------------------------
Ariel Palazzesi

*“Si cualquier habilidad que aprende un niño será obsoleta antes de que la
use, entonces, ¿qué es lo que tiene que aprender? La respuesta es obvia: La
única habilidad competitiva a largo plazo es la habilidad para
aprender“.*Seymour Papert


2014-04-24 12:41 GMT-03:00 Juan Carlos <juancarlospaco-***@public.gmane.org>:

> 2014-04-24 12:24 GMT-03:00 Roberto Alsina <ralsina-***@public.gmane.org>:
>
>> Python es un lenguaje que tiene un montón de implementaciones. Unas
>> cuantas de esas son compiladas, incluyendo, pero no limitadas a:
>>
>> Nuitka
>
>
>
> https://www.youtube.com/watch?v=wsczq6j3_bA#t=1426
>
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> 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
>
Claudio Freire
2014-04-24 16:17:28 UTC
Permalink
2014-04-24 13:00 GMT-03:00 Ariel Palazzesi <arielpalazzesi-***@public.gmane.org>:
> Con "grandes" me refiero a aplicaciones para la gestión de comercios o cosas
> asi, con decenas o cientos de archivos .py, etc. Yo lo vehia casi como un
> lenguaje para hacer pequeños scripts.
>
> Al ver que se utiliza en esos entornos, me surgio la duda de la compilacion
> para optimizar la velocidad de ejecución y para proteger el código fuente.

Python (casi todas las implementaciones) se compila a bytecode. Es
posible distribuir sólo el bytecode, sin el código fuente, y va a
correr (y de hecho acelera un poquito el startup porque evita tener
que compilar la fuenta a bytecode).

En términos de protección del código, sin embargo, el bytecode de
python es sencillamente des-compilable. Se pueden obfuscar los
identificadores internos durante la compilación a bytecode (hay
herramientas para eso, que modifican lo que no hace a la interfaz,
como variables locales), pero lo que se gana ahí es poco.

Es raro que en gestión de comercios tengas código de performance
realmente crítica - todo suele estar limitado por una base de datos o
el input del usuario. Pero si lo tuvieras, tenés algunas opciones. Sin
embargo, empaquetar algo que utilice eso te va a ser más complicado -
lo más sencillo de empaquetar es código puramente python. Eso se hace
sencillo con cx_freeze: http://cx-freeze.sourceforge.net/
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Roberto Alsina
2014-04-24 16:19:36 UTC
Permalink
On 24/04/14 13:17, Claudio Freire wrote:
> 2014-04-24 13:00 GMT-03:00 Ariel Palazzesi <arielpalazzesi-***@public.gmane.org>:
>> Con "grandes" me refiero a aplicaciones para la gestión de comercios o cosas
>> asi, con decenas o cientos de archivos .py, etc. Yo lo vehia casi como un
>> lenguaje para hacer pequeños scripts.
>>
>> Al ver que se utiliza en esos entornos, me surgio la duda de la compilacion
>> para optimizar la velocidad de ejecución y para proteger el código fuente.
> Python (casi todas las implementaciones) se compila a bytecode. Es
> posible distribuir sólo el bytecode, sin el código fuente, y va a
> correr (y de hecho acelera un poquito el startup porque evita tener
> que compilar la fuenta a bytecode).
>
> En términos de protección del código, sin embargo, el bytecode de
> python es sencillamente des-compilable. Se pueden obfuscar los
> identificadores internos durante la compilación a bytecode (hay
> herramientas para eso, que modifican lo que no hace a la interfaz,
> como variables locales), pero lo que se gana ahí es poco.
>
> Es raro que en gestión de comercios tengas código de performance
> realmente crítica - todo suele estar limitado por una base de datos o
> el input del usuario. Pero si lo tuvieras, tenés algunas opciones. Sin
> embargo, empaquetar algo que utilice eso te va a ser más complicado -
> lo más sencillo de empaquetar es código puramente python. Eso se hace
> sencillo con cx_freeze: http://cx-freeze.sourceforge.net/

Pero sacar el python de un exe de cx_freeze es una pavada.
En general tratar de esconder el código no es una actividad que tenga un
gran beneficio, porque en la gran mayoría de los casos lo que quiere el
"chorro" es usar el código, no leerlo.

_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Gilgamezh
2014-04-24 16:45:05 UTC
Permalink
El 2014-04-24 13:19, Roberto Alsina escribió:
> On 24/04/14 13:17, Claudio Freire wrote:
>> 2014-04-24 13:00 GMT-03:00 Ariel Palazzesi <arielpalazzesi-***@public.gmane.org>:
>>> Con "grandes" me refiero a aplicaciones para la gestión de comercios
>>> o cosas
>>> asi, con decenas o cientos de archivos .py, etc. Yo lo vehia casi
>>> como un
>>> lenguaje para hacer pequeños scripts.
>>>
>>> Al ver que se utiliza en esos entornos, me surgio la duda de la
>>> compilacion
>>> para optimizar la velocidad de ejecución y para proteger el código
>>> fuente.
>> Python (casi todas las implementaciones) se compila a bytecode. Es
>> posible distribuir sólo el bytecode, sin el código fuente, y va a
>> correr (y de hecho acelera un poquito el startup porque evita tener
>> que compilar la fuenta a bytecode).
>>
>> En términos de protección del código, sin embargo, el bytecode de
>> python es sencillamente des-compilable. Se pueden obfuscar los
>> identificadores internos durante la compilación a bytecode (hay
>> herramientas para eso, que modifican lo que no hace a la interfaz,
>> como variables locales), pero lo que se gana ahí es poco.
>>
>> Es raro que en gestión de comercios tengas código de performance
>> realmente crítica - todo suele estar limitado por una base de datos o
>> el input del usuario. Pero si lo tuvieras, tenés algunas opciones. Sin
>> embargo, empaquetar algo que utilice eso te va a ser más complicado -
>> lo más sencillo de empaquetar es código puramente python. Eso se hace
>> sencillo con cx_freeze: http://cx-freeze.sourceforge.net/
>
> Pero sacar el python de un exe de cx_freeze es una pavada.
> En general tratar de esconder el código no es una actividad que tenga
> un gran beneficio, porque en la gran mayoría de los casos lo que
> quiere el "chorro" es usar el código, no leerlo.
>
> _______________________________________________
> pyar mailing list pyar-+***@public.gmane.org



Creo que nos perdimos de algo en la pregunta original.
No hay un compilador, normalmente las maquinas que ejecutan programas en
python tienen instalado el interprete python y las librerías necesita
ese programa. Así de simple, creo que el 99% de los casos no necesitan
otra cosa.

Con respecto a la performance, te recomiendo que busques una charla de
una pycon (creo que es de Facundobatista) "Python más rápido que C" y la
semana pasada estuve leyendo este hilo en reddit con cosas re
interesantes:

http://www.reddit.com/r/Python/comments/23ap65/what_kind_of_project_would_you_not_use_python_for/

:D

saludos!

Gilgamezh.


_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Javier Marcon
2014-04-24 17:14:10 UTC
Permalink
El 24/04/14 13:45, Gilgamezh escribió:
>
> El 2014-04-24 13:19, Roberto Alsina escribió:
>> On 24/04/14 13:17, Claudio Freire wrote:
>>> 2014-04-24 13:00 GMT-03:00 Ariel Palazzesi <arielpalazzesi-***@public.gmane.org>:
>>>> Con "grandes" me refiero a aplicaciones para la gestión de
>>>> comercios o cosas
>>>> asi, con decenas o cientos de archivos .py, etc. Yo lo vehia casi
>>>> como un
>>>> lenguaje para hacer pequeños scripts.
>>>>
>>>> Al ver que se utiliza en esos entornos, me surgio la duda de la
>>>> compilacion
>>>> para optimizar la velocidad de ejecución y para proteger el código
>>>> fuente.
>>> Python (casi todas las implementaciones) se compila a bytecode. Es
>>> posible distribuir sólo el bytecode, sin el código fuente, y va a
>>> correr (y de hecho acelera un poquito el startup porque evita tener
>>> que compilar la fuenta a bytecode).
>>>
>>> En términos de protección del código, sin embargo, el bytecode de
>>> python es sencillamente des-compilable. Se pueden obfuscar los
>>> identificadores internos durante la compilación a bytecode (hay
>>> herramientas para eso, que modifican lo que no hace a la interfaz,
>>> como variables locales), pero lo que se gana ahí es poco.
>>>
>>> Es raro que en gestión de comercios tengas código de performance
>>> realmente crítica - todo suele estar limitado por una base de datos o
>>> el input del usuario. Pero si lo tuvieras, tenés algunas opciones. Sin
>>> embargo, empaquetar algo que utilice eso te va a ser más complicado -
>>> lo más sencillo de empaquetar es código puramente python. Eso se hace
>>> sencillo con cx_freeze: http://cx-freeze.sourceforge.net/
>>
>> Pero sacar el python de un exe de cx_freeze es una pavada.
>> En general tratar de esconder el código no es una actividad que tenga
>> un gran beneficio, porque en la gran mayoría de los casos lo que
>> quiere el "chorro" es usar el código, no leerlo.
>>
>> _______________________________________________
>> pyar mailing list pyar-+***@public.gmane.org
>
>
>
> Creo que nos perdimos de algo en la pregunta original.
> No hay un compilador, normalmente las maquinas que ejecutan programas
> en python tienen instalado el interprete python y las librerías
> necesita ese programa. Así de simple, creo que el 99% de los casos no
> necesitan otra cosa.
>
> Con respecto a la performance, te recomiendo que busques una charla de
> una pycon (creo que es de Facundobatista) "Python más rápido que C" y
> la semana pasada estuve leyendo este hilo en reddit con cosas re
> interesantes:
>
> http://www.reddit.com/r/Python/comments/23ap65/what_kind_of_project_would_you_not_use_python_for/
>
>
> :D
>
> saludos!
>
> Gilgamezh.
>
Yo uso py2exe, que te permite en forma sencilla generar un exe con lo
que tienetu programa python y las librerias, y asi a los clientes les
doy el exe para que ejecuten en lugar de tener que instalar el python en
cada maquina del cliente.

Salu2,

Javier.
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Sebastián Seba
2014-04-24 17:19:13 UTC
Permalink
El 24 de abril de 2014, 14:14, Javier Marcon <javiermarcon-***@public.gmane.org>escribió:

> El 24/04/14 13:45, Gilgamezh escribió:
> >
> > El 2014-04-24 13:19, Roberto Alsina escribió:
> >> On 24/04/14 13:17, Claudio Freire wrote:
> >>> 2014-04-24 13:00 GMT-03:00 Ariel Palazzesi <arielpalazzesi-***@public.gmane.org>:
> >>>> Con "grandes" me refiero a aplicaciones para la gestión de
> >>>> comercios o cosas
> >>>> asi, con decenas o cientos de archivos .py, etc. Yo lo vehia casi
> >>>> como un
> >>>> lenguaje para hacer pequeños scripts.
> >>>>
> >>>> Al ver que se utiliza en esos entornos, me surgio la duda de la
> >>>> compilacion
> >>>> para optimizar la velocidad de ejecución y para proteger el código
> >>>> fuente.
> >>> Python (casi todas las implementaciones) se compila a bytecode. Es
> >>> posible distribuir sólo el bytecode, sin el código fuente, y va a
> >>> correr (y de hecho acelera un poquito el startup porque evita tener
> >>> que compilar la fuenta a bytecode).
> >>>
> >>> En términos de protección del código, sin embargo, el bytecode de
> >>> python es sencillamente des-compilable. Se pueden obfuscar los
> >>> identificadores internos durante la compilación a bytecode (hay
> >>> herramientas para eso, que modifican lo que no hace a la interfaz,
> >>> como variables locales), pero lo que se gana ahí es poco.
> >>>
> >>> Es raro que en gestión de comercios tengas código de performance
> >>> realmente crítica - todo suele estar limitado por una base de datos o
> >>> el input del usuario. Pero si lo tuvieras, tenés algunas opciones. Sin
> >>> embargo, empaquetar algo que utilice eso te va a ser más complicado -
> >>> lo más sencillo de empaquetar es código puramente python. Eso se hace
> >>> sencillo con cx_freeze: http://cx-freeze.sourceforge.net/
> >>
> >> Pero sacar el python de un exe de cx_freeze es una pavada.
> >> En general tratar de esconder el código no es una actividad que tenga
> >> un gran beneficio, porque en la gran mayoría de los casos lo que
> >> quiere el "chorro" es usar el código, no leerlo.
> >>
> >> _______________________________________________
> >> pyar mailing list pyar-+***@public.gmane.org
> >
> >
> >
> > Creo que nos perdimos de algo en la pregunta original.
> > No hay un compilador, normalmente las maquinas que ejecutan programas
> > en python tienen instalado el interprete python y las librerías
> > necesita ese programa. Así de simple, creo que el 99% de los casos no
> > necesitan otra cosa.
> >
> > Con respecto a la performance, te recomiendo que busques una charla de
> > una pycon (creo que es de Facundobatista) "Python más rápido que C" y
> > la semana pasada estuve leyendo este hilo en reddit con cosas re
> > interesantes:
> >
> >
> http://www.reddit.com/r/Python/comments/23ap65/what_kind_of_project_would_you_not_use_python_for/
> >
> >
> > :D
> >
> > saludos!
> >
> > Gilgamezh.
> >
> Yo uso py2exe, que te permite en forma sencilla generar un exe con lo
> que tienetu programa python y las librerias, y asi a los clientes les
> doy el exe para que ejecuten en lugar de tener que instalar el python en
> cada maquina del cliente.
>
> Salu2,
>
> Javier.
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> 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
>

Estaba por comentar acerca de la charla de Brandon Rhodes que publicó Juan
Carlos así que +1 a eso :D
Roberto Alsina
2014-04-24 17:21:55 UTC
Permalink
On 24/04/14 14:14, Javier Marcon wrote:
> >Creo que nos perdimos de algo en la pregunta original.
> >No hay un compilador, normalmente las maquinas que ejecutan programas
> >en python tienen instalado el interprete python y las librerías
> >necesita ese programa. Así de simple, creo que el 99% de los casos no
> >necesitan otra cosa.
> >

Me parece que te perdiste la respuesta, hay por lo menos cinco
compiladores :-)

_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Gilgamezh
2014-04-24 20:19:41 UTC
Permalink
El 2014-04-24 14:21, Roberto Alsina escribió:
> On 24/04/14 14:14, Javier Marcon wrote:
>> >Creo que nos perdimos de algo en la pregunta original.
>> >No hay un compilador, normalmente las maquinas que ejecutan programas
>> >en python tienen instalado el interprete python y las librerías
>> >necesita ese programa. Así de simple, creo que el 99% de los casos no
>> >necesitan otra cosa.
>> >
>
> Me parece que te perdiste la respuesta, hay por lo menos cinco
> compiladores :-)
>

Claro, pero la pregunta de Ariel apuntaba a cuál es el denominador
común.

> 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.


Lo que salió después está buenisimo pero responder que existen
compiladores no responde lo de "¿Hay algun compilador para el? O
siempre se interpreta?".
Yo creo que el 99% de las veces se interpreta. Para alguién que recién
arranca con python (como yo) sería raro ponerte a usar alguna de las
otras implementaciones.


Lo copado es que ahora sabemos que se interpreta pero que también se
puede compilar al menos de cinco maneras diferentes :D

saludos!

Gilgamezh.



_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Roberto Alsina
2014-04-24 20:25:40 UTC
Permalink
On 24/04/14 17:19, Gilgamezh wrote:
>
> El 2014-04-24 14:21, Roberto Alsina escribió:
>> On 24/04/14 14:14, Javier Marcon wrote:
>>> >Creo que nos perdimos de algo en la pregunta original.
>>> >No hay un compilador, normalmente las maquinas que ejecutan programas
>>> >en python tienen instalado el interprete python y las librerías
>>> >necesita ese programa. Así de simple, creo que el 99% de los casos no
>>> >necesitan otra cosa.
>>> >
>>
>> Me parece que te perdiste la respuesta, hay por lo menos cinco
>> compiladores :-)
>>
>
> Claro, pero la pregunta de Ariel apuntaba a cuál es el denominador común.
>

Eh?

>> 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.
>
>
> Lo que salió después está buenisimo pero responder que existen
> compiladores no responde lo de "¿Hay algun compilador para el? O
> siempre se interpreta?".
> Yo creo que el 99% de las veces se interpreta. Para alguién que recién
> arranca con python (como yo) sería raro ponerte a usar alguna de las
> otras implementaciones.
>

Si alguien pregunta "¿Hay un compilador para él?" la respuesta es "sí",
no hay mucha vuelta para darle :-)
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Fernando Pelliccioni
2014-04-28 22:41:10 UTC
Permalink
2014-04-24 13:45 GMT-03:00 Gilgamezh <listas-***@public.gmane.org>:

>
> El 2014-04-24 13:19, Roberto Alsina escribió:
>
> On 24/04/14 13:17, Claudio Freire wrote:
>>
>>> 2014-04-24 13:00 GMT-03:00 Ariel Palazzesi <arielpalazzesi-***@public.gmane.org>:
>>>
>>>> Con "grandes" me refiero a aplicaciones para la gestión de comercios o
>>>> cosas
>>>> asi, con decenas o cientos de archivos .py, etc. Yo lo vehia casi como
>>>> un
>>>> lenguaje para hacer pequeños scripts.
>>>>
>>>> Al ver que se utiliza en esos entornos, me surgio la duda de la
>>>> compilacion
>>>> para optimizar la velocidad de ejecución y para proteger el código
>>>> fuente.
>>>>
>>> Python (casi todas las implementaciones) se compila a bytecode. Es
>>> posible distribuir sólo el bytecode, sin el código fuente, y va a
>>> correr (y de hecho acelera un poquito el startup porque evita tener
>>> que compilar la fuenta a bytecode).
>>>
>>> En términos de protección del código, sin embargo, el bytecode de
>>> python es sencillamente des-compilable. Se pueden obfuscar los
>>> identificadores internos durante la compilación a bytecode (hay
>>> herramientas para eso, que modifican lo que no hace a la interfaz,
>>> como variables locales), pero lo que se gana ahí es poco.
>>>
>>> Es raro que en gestión de comercios tengas código de performance
>>> realmente crítica - todo suele estar limitado por una base de datos o
>>> el input del usuario. Pero si lo tuvieras, tenés algunas opciones. Sin
>>> embargo, empaquetar algo que utilice eso te va a ser más complicado -
>>> lo más sencillo de empaquetar es código puramente python. Eso se hace
>>> sencillo con cx_freeze: http://cx-freeze.sourceforge.net/
>>>
>>
>> Pero sacar el python de un exe de cx_freeze es una pavada.
>> En general tratar de esconder el código no es una actividad que tenga
>> un gran beneficio, porque en la gran mayoría de los casos lo que
>> quiere el "chorro" es usar el código, no leerlo.
>>
>> _______________________________________________
>> pyar mailing list pyar-+***@public.gmane.org
>>
>
>
>
> Creo que nos perdimos de algo en la pregunta original.
> No hay un compilador, normalmente las maquinas que ejecutan programas en
> python tienen instalado el interprete python y las librerías necesita ese
> programa. Así de simple, creo que el 99% de los casos no necesitan otra
> cosa.
>
> Con respecto a la performance, te recomiendo que busques una charla de una
> pycon (creo que es de Facundobatista) "Python más rápido que C" y la semana
> pasada estuve leyendo este hilo en reddit con cosas re interesantes:
>


Pido disculpas a Facundo y los integrantes de esta lista, no quiero herir
susceptibilidades pero tengo que ser franco.
Considero que la charla que menciona Gilgamezh ("Python más rápido que C")
tiene muchos puntos flacos.
Python muchas ventajas por sobre C, pero la eficiencia no es una de ellas,
creo que ni siquiera son comparables en ese aspecto.
Si les interesa, podemos crear otro thread donde discutamos los detalles y
luego codificar algoritmos en distintos lenguajes y medirlos.
Creo que puede ser un buen ejercicio.




>
> http://www.reddit.com/r/Python/comments/23ap65/what_
> kind_of_project_would_you_not_use_python_for/
>
> :D
>
> saludos!
>
> Gilgamezh.
>
>
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> 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
>
Facundo Batista
2014-04-29 01:56:02 UTC
Permalink
2014-04-28 19:41 GMT-03:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:

> Pido disculpas a Facundo y los integrantes de esta lista, no quiero herir
> susceptibilidades pero tengo que ser franco.
> Considero que la charla que menciona Gilgamezh ("Python más rápido que C")
> tiene muchos puntos flacos.

¿Cuales?


> Python muchas ventajas por sobre C, pero la eficiencia no es una de ellas,
> creo que ni siquiera son comparables en ese aspecto.
> Si les interesa, podemos crear otro thread donde discutamos los detalles y
> luego codificar algoritmos en distintos lenguajes y medirlos.
> Creo que puede ser un buen ejercicio.

Eso es exactamente lo que hace la charla ;)

Slds.

--
. Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Twitter: @facundobatista
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Fernando Pelliccioni
2014-04-29 02:26:14 UTC
Permalink
2014-04-28 22:56 GMT-03:00 Facundo Batista <facundobatista-***@public.gmane.org>:

> 2014-04-28 19:41 GMT-03:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:
>
> > Pido disculpas a Facundo y los integrantes de esta lista, no quiero herir
> > susceptibilidades pero tengo que ser franco.
> > Considero que la charla que menciona Gilgamezh ("Python más rápido que
> C")
> > tiene muchos puntos flacos.
>
> ¿Cuales?
>

Arranco explicando mis puntos en otro thread, pero mañana, ya es tarde.

>
>
> > Python muchas ventajas por sobre C, pero la eficiencia no es una de
> ellas,
> > creo que ni siquiera son comparables en ese aspecto.
> > Si les interesa, podemos crear otro thread donde discutamos los detalles
> y
> > luego codificar algoritmos en distintos lenguajes y medirlos.
> > Creo que puede ser un buen ejercicio.
>
> Eso es exactamente lo que hace la charla ;)
>

Sí, lo se, pero es bueno hacerlo entre todos para ir aprendiendo en el
camino.


>
> Slds.
>
>
Abrazo!


> --
> . Facundo
>
> Blog: http://www.taniquetil.com.ar/plog/
> PyAr: http://www.python.org/ar/
> Twitter: @facundobatista
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> 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
>
Juan Carlos
2014-04-29 11:20:49 UTC
Permalink
2014-04-28 23:26 GMT-03:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:

>
>
>
> 2014-04-28 22:56 GMT-03:00 Facundo Batista <facundobatista-***@public.gmane.org>:
>
> 2014-04-28 19:41 GMT-03:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:
>>
>> > Pido disculpas a Facundo y los integrantes de esta lista, no quiero
>> herir
>> > susceptibilidades pero tengo que ser franco.
>> > Considero que la charla que menciona Gilgamezh ("Python más rápido que
>> C")
>> > tiene muchos puntos flacos.
>>
>> ¿Cuales?
>>
>
> Arranco explicando mis puntos en otro thread, pero mañana, ya es tarde.
>
>>
>>
>> > Python muchas ventajas por sobre C, pero la eficiencia no es una de
>> ellas,
>> > creo que ni siquiera son comparables en ese aspecto.
>> > Si les interesa, podemos crear otro thread donde discutamos los
>> detalles y
>> > luego codificar algoritmos en distintos lenguajes y medirlos.
>> > Creo que puede ser un buen ejercicio.
>>
>

Nuitka tiene opcion para traducir Python a C, esta en etapa experimental
actualmente, ademas de traducir a C++ de siempre...
Daniel
2014-04-29 11:33:29 UTC
Permalink
Pido disculpas a Facundo y los integrantes de esta lista, no quiero herir
> susceptibilidades pero tengo que ser franco.
> Considero que la charla que menciona Gilgamezh ("Python más rápido que C")
> tiene muchos puntos flacos.
> Python muchas ventajas por sobre C, pero la eficiencia no es una de ellas,
> creo que ni siquiera son comparables en ese aspecto.
> Si les interesa, podemos crear otro thread donde discutamos los detalles y
> luego codificar algoritmos en distintos lenguajes y medirlos.
> Creo que puede ser un buen ejercicio.
>
>
> Habría primero que definir eficiencia ... justamente ayer con un cliente y
usando python+django en 40 minutos desde 0 hicimos una prueba
de concepto funcional (9 modelos con muchas relaciones cruzadas. ¡y
anduvo!), para mi eso es eficiencia, dudo mucho que _yo_ lo hubiera podido
hacer con otro lenguaje. Ni siquiera con un gestor de base de datos. Antes
que se midan conmigo y digan que lo podrían hacer mucho más rápido que yo,
la intención es simplemente comentar un poco el concepto de eficiencia que
tengo. Para mi Python es el lenguaje más eficiente que he probado.

http://lema.rae.es/drae/?val=eficiciencia
http://lema.rae.es/drae/?val=eficacia
Luis Masuelli
2014-04-29 14:41:18 UTC
Permalink
Django no aplica para el concepto de "eficiencia" descrito en esa charla (si, esa charla fue en la UNNOBA, Junín , la PyCon a la que pude ir). Las aplicaciones Django estan atadas a peticiones web, trasmision HTTP, y respuestas de usuario. Las aplicaciones sobre las que trataba la charla estan atadas a conceptos de procesamiento intensivo en un CPU. Por lo tanto el concepto de eficiencia relacionado de esta forma al django (mas bien yo diria productividad, ya q xa nosotros eficiencia suele significar otras cosas), no es compatible con el concepto de eficiencia descrito en la charla (y que es el concepto de eficiencia normalmente llamado "eficiencia" en la programación y el testeo).

Date: Tue, 29 Apr 2014 08:33:29 -0300
From: dmlistapython-***@public.gmane.org
To: pyar-+ZN9ApsXKcFd+***@public.gmane.org
Subject: Re: [pyar] ¿Existe algo asi como un "compilador" Python?




Pido disculpas a Facundo y los integrantes de esta lista, no quiero herir susceptibilidades pero tengo que ser franco.Considero que la charla que menciona Gilgamezh ("Python más rápido que C") tiene muchos puntos flacos.

Python muchas ventajas por sobre C, pero la eficiencia no es una de ellas, creo que ni siquiera son comparables en ese aspecto.Si les interesa, podemos crear otro thread donde discutamos los detalles y luego codificar algoritmos en distintos lenguajes y medirlos.

Creo que puede ser un buen ejercicio.

Habría primero que definir eficiencia ... justamente ayer con un cliente y usando python+django en 40 minutos desde 0 hicimos una prueba

de concepto funcional (9 modelos con muchas relaciones cruzadas. ¡y anduvo!), para mi eso es eficiencia, dudo mucho que _yo_ lo hubiera podido hacer con otro lenguaje. Ni siquiera con un gestor de base de datos. Antes que se midan conmigo y digan que lo podrían hacer mucho más rápido que yo, la intención es simplemente comentar un poco el concepto de eficiencia que tengo. Para mi Python es el lenguaje más eficiente que he probado.


http://lema.rae.es/drae/?val=eficiciencia
http://lema.rae.es/drae/?val=eficacia


_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
fisa
2014-04-29 15:19:02 UTC
Permalink
El día 29 de abril de 2014, 11:41, Luis Masuelli
<luismasuelli-***@public.gmane.org> escribió:
> Django no aplica para el concepto de "eficiencia" descrito en esa charla
> (si, esa charla fue en la UNNOBA, Junín , la PyCon a la que pude ir). Las
> aplicaciones Django estan atadas a peticiones web, trasmision HTTP, y
> respuestas de usuario. Las aplicaciones sobre las que trataba la charla
> estan atadas a conceptos de procesamiento intensivo en un CPU. Por lo tanto
> el concepto de eficiencia relacionado de esta forma al django (mas bien yo
> diria productividad, ya q xa nosotros eficiencia suele significar otras
> cosas), no es compatible con el concepto de eficiencia descrito en la charla
> (y que es el concepto de eficiencia normalmente llamado "eficiencia" en la
> programación y el testeo).
>

Si mal no recuerdo, justamente la charla hablaba de que tareas de cpu
solo *no* son una buena medida, ya que normalmente hay IO en el medio.

--
fisa - Juan Pedro Fisanotti
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Luis Masuelli
2014-04-29 20:45:25 UTC
Permalink
La verdad no me acuerdo si la charla hablaba de cosas de IO (no se si hubo otra charla además de la que hubo en la UNNOBA que se llame igual). De todas formas estoy mas que seguro que no se refería a cosas como aplicaciones WEB (ese día solo vi Django en una charla, Web2Py en otra charla, y ninguna de esas charlas fue la de python más rápido que C), x lo q no se refería a ese tipo de eficiencia. Ojo, que no está mi post para debatir sobre en qué tipo de eficiencias Python es bueno o no (ya que, por algo, existen cosas como extensiones en C). Es decir: bajo NINGUN punto de vista me haría más que una rutina muy puntual (DEMASIADO puntual y crítica) en ASM. Esto no se trata ni de juicios ni de preferencias de eficiencias, sino de separar mas bien los conceptos tocados.

> From: fisadev-***@public.gmane.org
> Date: Tue, 29 Apr 2014 12:19:02 -0300
> To: pyar-+ZN9ApsXKcFd+***@public.gmane.org
> Subject: Re: [pyar] ¿Existe algo asi como un "compilador" Python?
>
> El día 29 de abril de 2014, 11:41, Luis Masuelli
> <luismasuelli-***@public.gmane.org> escribió:
> > Django no aplica para el concepto de "eficiencia" descrito en esa charla
> > (si, esa charla fue en la UNNOBA, Junín , la PyCon a la que pude ir). Las
> > aplicaciones Django estan atadas a peticiones web, trasmision HTTP, y
> > respuestas de usuario. Las aplicaciones sobre las que trataba la charla
> > estan atadas a conceptos de procesamiento intensivo en un CPU. Por lo tanto
> > el concepto de eficiencia relacionado de esta forma al django (mas bien yo
> > diria productividad, ya q xa nosotros eficiencia suele significar otras
> > cosas), no es compatible con el concepto de eficiencia descrito en la charla
> > (y que es el concepto de eficiencia normalmente llamado "eficiencia" en la
> > programación y el testeo).
> >
>
> Si mal no recuerdo, justamente la charla hablaba de que tareas de cpu
> solo *no* son una buena medida, ya que normalmente hay IO en el medio.
>
> --
> fisa - Juan Pedro Fisanotti
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> 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
2014-04-29 15:19:25 UTC
Permalink
El 29 de abril de 2014, 11:41, Luis Masuelli <luismasuelli-***@public.gmane.org>escribió:

> Django no aplica para el concepto de "eficiencia" descrito en esa charla
> (si, esa charla fue en la UNNOBA, Junín , la PyCon a la que pude ir). Las
> aplicaciones Django estan atadas a peticiones web, trasmision HTTP, y
> respuestas de usuario. Las aplicaciones sobre las que trataba la charla
> estan atadas a conceptos de procesamiento intensivo en un CPU. Por lo tanto
> el concepto de eficiencia relacionado de esta forma al django (mas bien yo
> diria productividad, ya q xa nosotros eficiencia suele significar otras
> cosas), no es compatible con el concepto de eficiencia descrito en la
> charla (y que es el concepto de eficiencia normalmente llamado "eficiencia"
> en la programación y el testeo).
>
> ------------------------------
>
>

Entonces... según tu muy válido concepto eficiencia, que no es el mismo
concepto que yo escuché en la charla, porque también incluyen el tiempo de
desarrollo (al menos si estamos hablando de la misma charla). No te queda
mucho más que programar en assembler :)
-Igual yo la corto acá porque no era la intención crear un flame en la
lista sino dar mi punto de vista. -
Saludos


>
>
> Pido disculpas a Facundo y los integrantes de esta lista, no quiero herir
> susceptibilidades pero tengo que ser franco.
> Considero que la charla que menciona Gilgamezh ("Python más rápido que C")
> tiene muchos puntos flacos.
> Python muchas ventajas por sobre C, pero la eficiencia no es una de ellas,
> creo que ni siquiera son comparables en ese aspecto.
> Si les interesa, podemos crear otro thread donde discutamos los detalles y
> luego codificar algoritmos en distintos lenguajes y medirlos.
> Creo que puede ser un buen ejercicio.
>
>
> Habría primero que definir eficiencia ... justamente ayer con un cliente y
> usando python+django en 40 minutos desde 0 hicimos una prueba
> de concepto funcional (9 modelos con muchas relaciones cruzadas. ¡y
> anduvo!), para mi eso es eficiencia, dudo mucho que _yo_ lo hubiera podido
> hacer con otro lenguaje. Ni siquiera con un gestor de base de datos. Antes
> que se midan conmigo y digan que lo podrían hacer mucho más rápido que yo,
> la intención es simplemente comentar un poco el concepto de eficiencia que
> tengo. Para mi Python es el lenguaje más eficiente que he probado.
>
> http://lema.rae.es/drae/?val=eficiciencia
> http://lema.rae.es/drae/?val=eficacia
>
> _______________________________________________ pyar mailing list
> pyar-+ZN9ApsXKcFd+***@public.gmane.org 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
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> 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
Claudio Freire
2014-04-29 16:54:51 UTC
Permalink
2014-04-29 12:19 GMT-03:00 Daniel <dmlistapython-***@public.gmane.org>:
>
> Entonces... según tu muy válido concepto eficiencia, que no es el mismo
> concepto que yo escuché en la charla, porque también incluyen el tiempo de
> desarrollo (al menos si estamos hablando de la misma charla). No te queda
> mucho más que programar en assembler :)


No es del todo cierto eso.

La eficiencia de un programa (cualquiera, pero mucho más notoriamente
en assembler), depdende de los conocimientos (sobre optimización, *en
una arquitectura específica*) del programador.

Hay pocos programadores de assembler, tengo que aclarar, que saben lo
suficiente como para superar a un compilador moderno. Y esto es a
cambio de un costo de mantenimiento realmente obscenamente más alto:
no sólo tenés que mantener ahora un código, tenés que mantener uno por
cada arquitectura. Y a este nivel de optimización, cambios como "Sandy
Bridge vs Haswell" sí hacen diferencia. O sea, necesitás un código
diferente para cada versión del procesador. Realmente no es algo que
quieras hacer a menos que realmente, realmente valga la pena.

Para todo lo demás, existe mast.... ehm.... el compilador (sea estático o JIT)
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Hernan Grecco
2014-04-24 23:41:39 UTC
Permalink
Hola,

2014-04-24 12:24 GMT-03:00 Roberto Alsina <ralsina-***@public.gmane.org>:
> On 24/04/14 12:21, Gabriel Acosta wrote:
>>
>> Python es un lenguaje interpretado, un código python no necesita ser
>> compilado, necesita de un intérprete que hace mas o menos algo asi como
>> 'compilar' pero no se genera un ejecutable. A qué te refieres con programas
>> grandes ?
>
>
> Python es un lenguaje que tiene un montón de implementaciones. Unas cuantas
> de esas son compiladas, incluyendo, pero no limitadas a:
>
> Nuitka, Jython, IronPython, PyPy, Shedskin.

Agrego dos mas:
- Numba: https://github.com/numba/numba
- Pyston: https://github.com/dropbox/pyston

Un saludo,

Hernán
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Walter R. Ojeda Valiente
2014-04-25 02:34:13 UTC
Permalink
Muy buena la discusión.

Saludos.

Walter.



2014-04-24 19:41 GMT-04:00 Hernan Grecco <hernan.grecco-***@public.gmane.org>:

> Hola,
>
> 2014-04-24 12:24 GMT-03:00 Roberto Alsina <ralsina-***@public.gmane.org>:
> > On 24/04/14 12:21, Gabriel Acosta wrote:
> >>
> >> Python es un lenguaje interpretado, un código python no necesita ser
> >> compilado, necesita de un intérprete que hace mas o menos algo asi como
> >> 'compilar' pero no se genera un ejecutable. A qué te refieres con
> programas
> >> grandes ?
> >
> >
> > Python es un lenguaje que tiene un montón de implementaciones. Unas
> cuantas
> > de esas son compiladas, incluyendo, pero no limitadas a:
> >
> > Nuitka, Jython, IronPython, PyPy, Shedskin.
>
> Agrego dos mas:
> - Numba: https://github.com/numba/numba
> - Pyston: https://github.com/dropbox/pyston
>
> Un saludo,
>
> Hernán
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> 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
>



--
Hay 10 clases de personas. Las que conocen aritmética binaria y las que no.
Ariel Palazzesi
2014-04-25 10:25:14 UTC
Permalink
Gracias por todas las respuestas!
Saludos.

--------------------------------------------------------------------------------------------------------------------------
Ariel Palazzesi

*“Si cualquier habilidad que aprende un niño será obsoleta antes de que la
use, entonces, ¿qué es lo que tiene que aprender? La respuesta es obvia: La
única habilidad competitiva a largo plazo es la habilidad para
aprender“.*Seymour Papert


2014-04-24 23:34 GMT-03:00 Walter R. Ojeda Valiente <wojedav-***@public.gmane.org>:

> Muy buena la discusión.
>
> Saludos.
>
> Walter.
>
>
>
> 2014-04-24 19:41 GMT-04:00 Hernan Grecco <hernan.grecco-***@public.gmane.org>:
>
> Hola,
>>
>> 2014-04-24 12:24 GMT-03:00 Roberto Alsina <ralsina-***@public.gmane.org>:
>> > On 24/04/14 12:21, Gabriel Acosta wrote:
>> >>
>> >> Python es un lenguaje interpretado, un código python no necesita ser
>> >> compilado, necesita de un intérprete que hace mas o menos algo asi como
>> >> 'compilar' pero no se genera un ejecutable. A qué te refieres con
>> programas
>> >> grandes ?
>> >
>> >
>> > Python es un lenguaje que tiene un montón de implementaciones. Unas
>> cuantas
>> > de esas son compiladas, incluyendo, pero no limitadas a:
>> >
>> > Nuitka, Jython, IronPython, PyPy, Shedskin.
>>
>> Agrego dos mas:
>> - Numba: https://github.com/numba/numba
>> - Pyston: https://github.com/dropbox/pyston
>>
>> Un saludo,
>>
>> Hernán
>> _______________________________________________
>> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
>> 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
>>
>
>
>
> --
> Hay 10 clases de personas. Las que conocen aritmética binaria y las que
> no.
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> 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
>
fisa
2014-04-24 21:36:24 UTC
Permalink
El día 24 de abril de 2014, 12:12, Ariel Palazzesi
<arielpalazzesi-***@public.gmane.org> 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-+ZN9ApsXKcFd+***@public.gmane.org
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
2014-04-24 21:47:32 UTC
Permalink
Es casi casi un artículo de la PET :)


El 24 de abril de 2014, 18:36, fisa <fisadev-***@public.gmane.org> escribió:

> El día 24 de abril de 2014, 12:12, Ariel Palazzesi
> <arielpalazzesi-***@public.gmane.org> 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-+ZN9ApsXKcFd+***@public.gmane.org
> 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
Claudio Freire
2014-04-24 22:23:59 UTC
Permalink
2014-04-24 18:36 GMT-03:00 fisa <fisadev-***@public.gmane.org>:
> 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.


Hay una diferencia sutil en un paso 3.b o 3.a, podríamos decirle, que
hace toda la diferencia entre C# y C++, o Java, PyPy y CPython.

El JIT.

Los intérpretes propiamente dichos, no "generan binario" para el
intermedio, sino que simplemente ejecutan las operaciones que el
intermedio describe. Está el binario del intérprete, pero es estático,
que consume datos del intermedio, y no un binario generado a partir
del intermedio. Eso hace CPython.

C#, Java y PyPy, lo que hacen, es efectivamente generar binario para
el intermedio, a medida que se da cuenta que podría ser más rápido que
interpretarlo. Eso es lo que se llama un JIT. Un lenguaje con JIT es
un bicho diferente a compilado o interpretado, tiene aspectos de
ambos, y tiene características de performance completamente
diferentes. Vale la pena hacer la diferencia.
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Sergio Schvezov
2014-04-24 23:36:54 UTC
Permalink
2014-04-24 18:36 GMT-03:00 fisa <fisadev-***@public.gmane.org>:

> El día 24 de abril de 2014, 12:12, Ariel Palazzesi
> <arielpalazzesi-***@public.gmane.org> 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.
>
> 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 ;)
>

Me parece más borroso que eso

Si defino que a binario a algo que le puedo pasar al sistema operativo y
ejecturar sin necesidad de un tercero(interprete), en otras palabras, es
nativo para el sistema operativo y arquitectura para la cual se compilo.

Java:
javac te compila a bytecode independiente de la plataforma[1], con java
ejecuto ese bytecode. Ahora si uso gcj para compilar, cambia todo, porque
también tengo la opción de generar un binario[2] :-)

Python:
python mi.py compila y ejecuta

Go:
Esto es casi lo mismo
go run main.go
go build && ./main

C/gcc:
gcc helloworld.c && ./a.out
g++ myQtApp.cpp && make coffee && play video games && socialize? &&
nocompileerrors && ./a.out

Entonces resumiendo:
- con compilaciones tradicionales me deshago del interprete y puedo
ejecutar y ya.
- ejecutar por medio del interprete implica compilar a algo y de que el
interprete se haga cargo de ser intermediario en mi sistema.
- a veces conviene compilar porque convertir a ese bytecode intermedio o
binario es muy lento (cosa que no se ve en python o go)
- el binario para ejecutar es batteries included en cuanto interacción con
mi sistema (excepcion por shared libs o dlopen)

Mi burda explicacion sin haber estudiado ciencias de la computacion o
parecidos.

[1] http://en.wikipedia.org/wiki/Java_compiler
[2] http://en.wikipedia.org/wiki/GNU_Compiler_for_Java
Matigro
2014-04-25 11:45:19 UTC
Permalink
El 24 de abril de 2014, 18:36, fisa<fisadev-***@public.gmane.org> escribió:

> Buenas! Después de ver el thread, me parece que suma que me tome el
> trabajo de armar una respuesta bien completa.
>

Sin aportar nada, pero desasnándome increiblemente!

Podrá subirse esto + lo de Claudio Freire + lo de Sergio Schvezov (que
serían los teóricos) a la Wiki? Yo lo puedo hacer, pero lo mío sería un
copy/paste intentando unirlas con muy poca lógica :)

Además, habría que sumarle las urls de los compiladores sugeridos.

Encontré http://python.org.ar/RendimientoPythonVsJavaVsNet que, sólo lo
ojié, es parecido y quizás habría que mejorar con esto.

Salute

--
http://www.linkedin.com/in/matiasgieco
Continue reading on narkive:
Loading...