Python, compiladores y GUI

[planeta9999]

 
Desde hace tiempo se habla mucho de Python, a mi solo me puede interesar si se puede Compilar, no puedo hacer un aplicativo comercial en el que el fuente esté a la vista.

Por otra parte desconozco si hay algún entorno gráfico de desarrollo, algo como QT Creator, me refiero a la posibilidad de crear aplicaciones gráficas, no solo una salida de texto vulgar y corriente.

Creo que sería interesante relacionar los compiladores y herramientas de desarrollo gráfico (GUI/IDE) disponibles para Python, trabajando para Windows, Linux, Android y Raspberry. Supongo que no hay nada para microcontroladores ARM.

Buscando ahora en un rato me encuentro estos compiladores:
1.- Py2exe para windows
2.- Nuitka (este creo que vale para Raspberry, pasa el fuente a C y compila vinculando a libpython )
3.- Cython

Entornos gráficos (GUI/IDE)
1.- Kivy (Linux, Windows, OS X, Android, iOS, Raspberry Pi)
2.- BOA Constructor

IDEs (creo que no son entornos gráficos)
1.- Pycharm
2.- PyDev
3.- Sublime Text 3
4.- Wing
5.- Vim
6.- Ninja Ide


Solo emplearé tiempo en aprender Python, cuando tenga claro estas dos herramientas, Compilador y Entorno Gráfico, de lo contrario no me interesa Python por muy chula y optimizada que sea su programación. Ninguna aplicación comercial puede estar basada en un lenguaje intérprete, por rendimiento y por no dejar a la vista el fuente. Y para desarrollos en PC o móviles, hace falta un entorno gráfico.

[AG1]

Hace tiempo utilice un compilador Phyton para una aplicación de un modem GSM de la firma Telit:
http://www.telit.com/fileadmin/user_upload/products/Downloads/3G/Telit_Easy_Script_Python_2.7_r5.pdf

El compilador te permitía entre otras cosas encriptar el código que se debía cargar en el modem. Era un compilador precario y lento pero era lo único que se podía utilizar para dicho modem. El código "compilado" de los archivos "pyc" que generaba erán
 de un tamaño excesivo. Creo que se trataba de una pseudo-compilación con la finalidad de encriptar algo el código a subir al modem.

Puedes echarle una mirada a los archivos "pyc" que generaba ese compilador: http://www.allm2m.com/Datalogger/Datalogger.zip

S2.

[planeta9999]

¿ Eso no será el bytecode, para que luego lo ejecute el intérprete ?, algo parecido a Java. Yo necesito una compilación que genere un binario puro y duro que se ejecute sin intérpretes ni RunTimes.

[Geo]

¿ Eso no será el bytecode, para que luego lo ejecute el intérprete ?, algo parecido a Java. Yo necesito una compilación que genere un binario puro y duro que se ejecute sin intérpretes ni RunTimes.

Si, es bytecode.

La línea principal de desarrollo de Python no incluye ningún tipo de "protección" para las aplicaciones (salvo por convertir a bytecode por defecto los módulos que son importados). Puedes checar la respuesta oficial en cuanto a la protección del código: https://wiki.python.org/moin/Asking%20for%20Help/How%20do%20you%20protect%20Python%20source%20code%3F

Solamente he usado Python para proyectos pequeños (scripts de apoyo para automatizar tareas), hace algunos meses busqué info también sobre este tema, Nuitka no lo conocía pero revisando la documentación me parece que puede ser la mejor opción, antes de eso estaba revisando info sobre Numba (http://numba.pydata.org/).

Para microcontroladores ARM tienes micropython (https://micropython.org/).

[tsk]

Con respecto a lo de la visibilidad del código lo puedes resolver por medio de la ofuscación.

https://liftoff.github.io/pyminifier/

De todas formas sea QT, C binario y/o lo que sea, siempre vas a poder realizar ingeniería inversa, por lo que vean o no el código pasa a ser irrelevante a menos que uses otras herramientas que te protejan del desensamblado y que ofusquen variables y funciones para hacer más difícil su interpretación.

[Geo]

Olvidé este enlace sobre frameworks GUI para Python: http://insights.dice.com/2017/08/07/7-top-python-gui-frameworks-for-2017-2/
He visto que mencionas que utilizas Qt, supongo que entonces te sería más familiar PyQt (https://riverbankcomputing.com/software/pyqt/intro).
Finalmente, sólo recordar que al utilizar la versión LGPL de Qt (no la de licencia comercial) hay algunas cosas que hay que cumplir: https://www.qt.io/faq/#_Toc_3_3

[planeta9999]

Con respecto a lo de la visibilidad del código lo puedes resolver por medio de la ofuscación.

https://liftoff.github.io/pyminifier/

De todas formas sea QT, C binario y/o lo que sea, siempre vas a poder realizar ingeniería inversa, por lo que vean o no el código pasa a ser irrelevante a menos que uses otras herramientas que te protejan del desensamblado y que ofusquen variables y funciones para hacer más difícil su interpretación.

Leí lo de la ofuscación, de todas formas también está la velocidad de proceso de un compilado frente a un intérprete.

Ahora mismo tengo un programa para Rasbperry, que debe de reproducir unos videos con OpenMax, mientras chequea en bucle un expansor de puertos MCP23S17 por SPI. Todo eso tiene que ser muy rápido, o el buffer de OpenMax para reproducir el video puede dar problemas.

De usar Python, solo será si encuentro una solución con un compilador y un entorno para desarrollos gráficos. Si que parece que los hay, será cuestión de ir probando.

[tsk]

También la velocidad, pero todo cambia cuando cambias la perspectiva de como se hacen las cosas en Linux.

En los sistemas Unix/Linux no pones todo en un sólo ejecutable, sino que los separas en varios componentes que al final se van a comunicar entre ellos por medio de tuberías (pipes).

Así por ejemplo puedes tener un proceso que revise el expansor SPI, otro proceso donde se esté ejecutando OpenMAX de forma independiente, o si quieres ponerlo todo en un sólo ejecutable puedes usar pthread.

Cualquier forma te permitiría poder esconder lo que quieras esconder, y darle un buen rendimiento a lo que le quieras dar un buen rendimiento:

GUI -- Python + GUI o cualquiera que se adapte
SPI -- Programa en C, ya sea como un programa independiente o también lo puedes hacer como módulo para el kernel, aunque me da la impresión de que ya existe el módulo de tal forma que le haces un modprobe mcp23xxx o algo similar.

De hecho, si existe:

Código: Bash

1. $ modinfo gpio-mcp23s08
2. filename:       /lib/modules/3.13.0-129-generic/kernel/drivers/gpio/gpio-mcp23s08.ko
3. license:        GPL
4. srcversion:     75D0D9B284073BDF12A326F
5. alias:          i2c:mcp23017
6. alias:          i2c:mcp23008
7. alias:          spi:mcp23s17
8. alias:          spi:mcp23s08
9. depends:        
10. intree:         Y
11. vermagic:       3.13.0-129-generic SMP mod_unload modversions
12. signer:         Magrathea: Glacier signing key
13. sig_key:        4B:73:11:88:5B:3D:E2:B1:8B:BD:C5:DB:5A:4C:EA:A0:F9:A9:AE:12
14. sig_hashalgo:   sha512

Al cargarlo te crea entradas dentro de /dev/spidevX.X

OpenMAX -- Programa en C independiente.

Como nota, también puedes crear módulos para python en C, por lo que el abanico de posibilidades se abre.

[planeta9999]

También la velocidad, pero todo cambia cuando cambias la perspectiva de como se hacen las cosas en Linux.

En los sistemas Unix/Linux no pones todo en un sólo ejecutable, sino que los separas en varios componentes que al final se van a comunicar entre ellos por medio de tuberías (pipes).

Así por ejemplo puedes tener un proceso que revise el expansor SPI, otro proceso donde se esté ejecutando OpenMAX de forma independiente, o si quieres ponerlo todo en un sólo ejecutable puedes usar pthread.

 
Esto si que lo desconozco por completo. A ver si encuentro información detallada de como hacerlo, porque no tengo ni idea. El programa en C++ ya lo tengo hecho para Raspberry, todo en un solo programa.