TechNotes

Python en Windows sin ventana de DOS

En Windows se puede ejecutar un programa escrito en Python haciendo doble clic sobre él, pues se asocian los archivos de extensión .py al intérprete durante la instalación de éste. Aún cuando el programa que se ejecuta es una aplicación gráfica, se abre una ventana de DOS, que está ahí para dejar disponibles la entrada y salida estándar y la salida de errores. Sin embargo, muchas veces no interesa que aparezca, pues puede resultar molesta, o incluso confundir a usuarios poco avanzados que usen la aplicación.

La forma más sencilla que he encontrado para evitar que aparezca esta ventana de DOS con los programas Python es cambiar la extensión del ejecutable principal de .py a .pyw, con esto en vez de abrirse con python.exe, se abrirá con pythonw.exe, que está pensado especialmente para estos casos

Problemas al compilar blas-atlas en Gentoo

Esta es una de esas entradas que pongo aquí sobre todo para evitar olvidarme si me enfrento de nuevo al mismo problema.

Ayer estaba en la biblioteca estudiando para un examen de control digital y necesitaba usar octave para hacer algunas pruebas. Descubrí con horror que iba mal cuando se quedó colgado al pedirle las raíces de un polinomio:

octave:1> v = roots([1 3 2 0 2])

Tuve que interrumpir la operación con el típico Ctrl+C porque, además, el octave estaba usando en ese momento el 100% de CPU según top. Lo sorprendente es que al volver a intentar la misma operación, en vez de colgarse, me mostró este error:

octave:1> v = roots([1 3 2 0 2])
error: dgeev failed to converge
error: evaluating assignment expression near line 65, column 9
error: evaluating if command near line 62, column 5
error: evaluating if command near line 59, column 3
error: called from `roots’ in file `/usr/share/octave/2.1.73/m/polynomial/roots.m’
error: evaluating assignment expression near line 1, column 3

El problema no sólo aparecía con la función roots, sino con muchas otra de las que necesitaba, que quizá usaban ésta en su código. Un poco de investigación al llegar a casa me hizo saber que el problema estaba en que había compilado la versión de octave ofrecida como estaba por Gentoo sin Blas entre sus uses. En el Changelog de octave decía que en la versión más reciente (2.1.73-r2), Blas había dejado de ser opcional.

Desenmascaré entonces esta versión de octave y comenzó la instalación de blas-atlas, que es una de las implementaciones de ¡Blas disponibles. Pero duró poco, la instalación se detuvo con un mensaje en pantalla que decía que tenía que ejecutar la instalación en modo interactivo. Seguí los pasos indicados pero, independientemente de las opciones que escogiese en el proceso, la compilación fallaba.

En un hilo del foro de Gentoo donde había un usuario quejándose del mismo problema que yo, el desarrollador encargado del ebuild de octave en Gentoo aconsejaba desenmascarar las últimas versiones de blas-atlas y blas-lapack (además de dos de sus dependencias que también estaban enmascaradas). Hecho esto repetí el intento de instalación y esta vez no sólo me hizo menos preguntas que antes sino que aparentemente estaba funcionando.

El proceso de compilación de blas-atlas es largo, y por la salida que ofrece en ocasiones parece que ha entrado en un ciclo infinito. Pero no pierdas la calma, que no es así; cada iteración es diferente y no se ciclan, así que resiste la tentación de cancelar. No puedo decir cuanto tardó porque me fui a dormir, pero esta mañana, cuando le pregunté a octave de nuevo por las raíces del mismo polinomio de ayer, me respondió esto rápidamente:

octave:1> v = roots([1 3 2 0 2])
v =
-1.79051 + 0.55231i
-1.79051 - 0.55231i
0.29051 + 0.69660i
0.29051 - 0.69660i

Una advertencia, aunque aparece en pantalla antes de empezar: Si tienes un procesador que ajusta su velocidad a las necesidades del software, desactiva esta opción y deja una velocidad fija de procesador durante la compilación, porque blas-atlas hace pruebas de rendimiento para optimizarse y una velocidad variable del procesador puede traer resultados no deseados.

Eso es todo, Jake out.

La codificación de caracteres en Python

Cuando escribimos un script en Python y éste contiene cadenas de caracteres que no están escritas en inglés, es posible que éstas contengan caracteres que no se encuentran entre los definidos por el ASCII. En este caso, si no se le dice a Python cómo debe tratarlas, éste se queja.

Tomemos, por ejemplo, este script que tan sólo muestra en pantalla una cadena de texto:

Si ejecutamos este script tal como está ahora, tendremos una desagradable sorpresa:

jake@aurora /tmp $ chmod u+x encoding.py
jake@aurora /tmp $ ./encoding.py
sys:1: DeprecationWarning: Non-ASCII character '\xc3' in file ./encoding.py on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
Las tildes no están a salvo en las cadenas de texto

La URL que devuelve el intérprete corresponde a una propuesta de extensión de Python (PEP), aceptada hace tiempo, que indica cómo especificar la codificación de caracteres no ASCII.

Básicamente, lo que dice es que Python interpreta todo como ASCII a menos que se le indique lo contrario con un comentario especial que tiene que estar en la primera o la segunda línea y debe casar con la expresión regular: coding[:=]\s*([-\w.]+). Esto significa que si usas Vim o emacs para editar el código python puedes utilizar la sintaxis propia de cada uno para indicarle al editor la codificación del archivo y así matar dos pájaros de un tiro. Además, como bien dice el artículo, se puede usar incluso el lenguaje natural; podría escribir:

Aunque yo prefiero usar la sintaxis de Vim, que es, dicho sea de paso, mi editor favorito

Y si ejecutamos esta nueva versión vemos que ahora no hay quejas:

jake@aurora /tmp $ ./encoding.py
Las tildes no están a salvo en las cadenas de texto