Python para todos por Raúl González duque

[3dpoder]

interactuar con webs
.Existen dos módulos principales para leer datos de urls en Python: urllib y urllib2. En esta lección aprenderemos a utilizar urllib2 ya que es mucho más completo, aunque urllib tiene funcionalidades propias que no se pueden encontrar en urllib2, por lo que también lo tocaremos de pasada.

Urllib2 puede leer datos de una url usando varios protocolos como htp, htps, ftp, o gopher.

Se utiliza una función urlopen para crear un objeto parecido a un fichero con el que leer de la url. Este objeto cuenta con métodos como read, readline, readlines y close, los cuales funcionan exactamente igual que en los objetos file, aunque en realidad estamos trabajando con un Wrapper que nos abstrae de un socket que se utiliza por debajo.

El método read, como recordareis, sirve para leer el archivo completo o el número de bytes especificado como parámetro, readline para leer una línea, y readlines para leer todas las líneas y devolver una lista con ellas.

También contamos con un par de métodos geturl, para obtener la url de la que estamos leyendo (que puede ser útil para comprobar si ha habido una redirección) e información que nos devuelve un objeto con las cabeceras de respuesta del servidor (a las que también se puede acceder mediante el atributo headers).

Import urllib2
Try:
F = urllib2.urlopen(http://www.Python, org)
Print f, read()
F, close ()
Except htperror, e:
Print ocurrió un error
Print eh, code.

Except urlerror, e:
Print ocurrió un error
Print eh, reason.

Al trabajar con urllib2 nos podemos encontrar, como vemos, con errores de tipo urlerror. Si trabajamos con htp podemos encontrarnos también con errores de la subclase de urlerror htperror, que se lanzan cuando el servidor devuelve un código de error htp, como el error 404 cuando no se encuentra el recurso. También podríamos encontrarnos con errores lanzados por la librería que urllib2 utiliza por debajo para las transferencias htp: httplib, o con excepciones lanzadas por el propio módulo socket.

La función urlopen cuenta con un parámetro opcional data con el que poder enviar información a direcciones htp (y solo htp) usando mensaje (los parámetros se envían en la propia petición), por ejemplo, para responder a un formulario. Este parámetro es una cadena codificada adecuadamente, siguiendo el formato utilizado en las urls.

password=contrase%a4a&usuario=Manuel.

Lo más sencillo para codificar la cadena es utilizar el método urlencode de urllib, que acepta un diccionario o una lista de tuplas (clave, valor) y genera la cadena codificada correspondiente.

Import urllib, urllib2
Params = urllib, urlencode ({usuario: Manuel, password: contraseña})
F = urllib2.urlopen(http://ejemplo.com/login, parámetros).

Si lo único que queremos hacer es descargar el contenido de una url a un archivo local, podemos utilizar la función urlretrieve de urllib en lugar de leer de un objeto creado con urlopen y escribir los datos leídos.

La función urlretrieve toma como parámetros la url a descargar.

Y, opcionalmente, un parámetro filename con la ruta local en la que guardar el archivo, un parámetro data similar al de urlopen y un parámetro reporthok con una función que utilizar para informar del progreso.

A excepción de las ocasiones en las que se utiliza el parámetro data las conexiones siempre se realizan utilizando get (los parámetros se envían en la url). Para enviar datos usando get basta concatenar la cadena resultante de urlencode con la url a la que nos vamos a conectar mediante el símbolo?

Params = urllib, urlencode ({usuario: Manuel, password: contraseña})
F = urllib2.urlopen(http://ejemplo.com/login +
? + parámetros).

En urllib también se utiliza una función urlopen para crear nuestros pseudo-archivos, pero a diferencia de la versión de urllib, la función urlopen de urllib2 también puede tomar como parámetro un objeto request, en lugar de la url y los datos a enviar.

La clase request define objetos que encapsulan toda la información relativa a una petición. A través de este objeto podemos realizar peticiones más complejas, añadiendo nuestras propias cabeceras, como el user-agent.

El constructor más sencillo para el objeto request no toma más que una cadena indicando la url a la que conectarse, por lo que utilizar este objeto como parámetro de urlopen sería equivalente a utilizar una cadena con la url directamente.

Sin embargo, el constructor de request también tiene como parámetros opcionales una cadena data para mandar datos por mensaje y un diccionario headers con las cabeceras (además de un par de campos origin_req_host y unverifiable, que quedan fuera del propósito del capítulo por ser de raro uso).

Veamos cómo añadir nuestras propias cabeceras utilizando como ejemplo la cabecera user-agent. El user-agent es una cabecera que sirve para identificar el navegador y sistema operativo que estamos utilizando para conectarnos a esa url. Por defecto urllib2 se identifica.

Como Python-urllib/2.5, si quisiéramos identificarnos como un Linux corriendo Konqueror, por ejemplo, usaríamos un código similar al siguiente.

Ua = Mozilla/5.0 (compatible, Konqueror/3.5.8; Linux)
H = {user-agent: ua}
R = urllib2. Request(http://www.Python, org, headers=h)
F = urllib2.urlopen(r)
Print f, read().

Para personalizar la forma en que trabaja urllib2 podemos instalar un grupo de manejadores (handler) agrupados en un objeto de la clase openerdirector (opener o abridor), que será el que se utilice a partir de ese momento al llamar a urlopen.

Para construir un opener se utiliza la función build_opener a la que se le pasa los manejadores que formaran parte del opener. El opener se encargara de encadenar la ejecución de los distintos manejadores en el orden dado. También se puede usar el constructor de openerdirector, y añadir los manejadores usando su método add_handler.

Para instalar el opener una vez creado se utiliza la función install_
Opener, que toma como parámetro el opener a instalar. También se podría, si sólo queremos abrir la url con ese opener una sola vez, utilizar el método open del opener.

Urllib2 cuenta con handler que se encargan de manejar los esquemas disponibles (htp, htps, ftp), manejar la autenticacción, manejar las redirecciones, etc.

Para añadir autenticación tendríamos que instalar un opener que incluyera como manejador htpbasicauthhandler, proxybasicauthhandler, htpdigestauthhandler y/o proxydigestauthhandler.

Para utilizar autenticación htp básica, por ejemplo, usaríamos.

Htpbasicauthhandler:
Aut_h = urllib2. Htpbasicauthhandler()
Aut_h, add_password(realm, host, usuario, password)
Opener = urllib2.build_opener(aut_h)
Urllib2.install_opener(opener)
F = urllib2.urlopen(http://www.Python, org).

Si quisiéramos especificar un proxy en el código tendríamos que utilizar un opener que contubiera el manejador proxyhandler. El manejador por defecto incluye una instacia de proxyhandler construido llamando al inicializador sin parámetros, con lo que se le la lista de proxies a utilizar de la variable de entorno adecuada. Sin embargo, también podemos construir un proxyhandler pasando como parámetro al inicializador un diccionario cuyas claves son los protocolos y los valores, la url del proxy a utilizar para dicho protocolo.

Proxy_h = urllib2. Proxyhandler({http : http://miproxy, net:123})
Opener = urllib2.build_opener(proxy_h)
Urllib2.install_opener(opener)
F = urllib2.urlopen(http://www.Python, org).

Para que se guarden las cookies que manda htp utilizamos el manejador htpcookieprocessor.

Cokie_h = urllib2. Htpcookieprocessor()
Opener = urllib2.build_opener(cokie_h)
Urllib2.install_opener(opener)
F = urllib2.urlopen(http://www.Python, org).

Si queremos acceder a estas cookies o poder mandar nuestras propias cookies, podemos pasarle como parámetro al inicializador de htpcookieprocessor un objeto de tipo cookiejar del módulo cokielib.

Para leer las cookies mandadas basta crear un objeto iterable a partir del cookiejar (también podríamos buscar las cabeceras correspondientes, pero este sistema es más claro y sencillo).

Import urllib2, cokielib.

Cokie_j = cokielib. Cookiejar()
Cokie_h = urllib2. Htpcookieprocessor(cokie_j)
Opener = urllib2.build_opener(cokie_h)
Opener, open(http://www.Python, org)
For num, cookie in enumerate (cokie_j):
Print num, cookie, name.

Print cookie, value.

Print.

En el improbable caso de que necesitáramos añadir una cookie antes.

De realizar la conexión, en lugar de conectarnos para que el sitio la mande, podríamos utilizar el método set_cokie de cookiejar, al que le pasamos un objeto de tipo cookie. El constructor de cookie, no obstante, es bastante complicado.

[3dpoder]

threads
¿Qué son los procesos y los hilos?
Las ordenadores serían mucho menos útiles si no pudiéramos hacer más de una cosa a la vez. Si no pudiéramos, por ejemplo, escuchar música en nuestro reproductor de audio favorito mientras leemos un tutorial de Python en mundo Gek.

Pero, ¿cómo se conseguía esto en ordenadores antiguas con un solo núcleo / una sola cpu? Lo que ocurría, y lo que ocurre ahora, es que en realidad no estamos ejecutando varios procesos a la vez (se llama proceso a un programa en ejecución), sino que los procesos se van turnando y, dada la velocidad a la que ejecutan las instrucciones, nosotros tenemos la impresión de que las tareas se ejecutan de forma paralela como si tuviéramos multitarea real.

Cada vez que un proceso distinto pasa a ejecutarse es necesario realizar lo que se llama un cambio de contexto, durante el cual se salva el estado del programa que se estaba ejecutando a memoria y se carga el estado del programa que va a entrar a ejecutarse.

En Python podemos crear nuevos procesos mediante la función os, Fork, que ejecuta la llamada al sistema Fork, o mediante otras funciones más avanzadas como popen2.popen2, de forma que nuestro programa pueda realizar varias tareas de forma paralela.

Sin embargo, el cambio de contexto puede ser relativamente lento, y los recursos necesarios para mantener el estado demasiados, por lo que ha menudo es mucho más eficaz utilizar lo que se conoce como hilos, hilos de ejecución, o procesos ligeros.

Los hilos son un concepto similar a los procesos: también se trata de código en ejecución. Sin embargo, los hilos se ejecutan dentro de un proceso, y los hilos del proceso comparten recursos entre sí, como la memoria, por ejemplo.

El sistema operativo necesita menos recursos para crear y gestionar los hilos, y al compartir recursos, el cambio de contexto es más rápido. Además, dado que los hilos comparten el mismo espacio de memoria global, es sencillo compartir información entre ellos: cualquier variable global que tengamos en nuestro programa es vista por todos los hilos.
el gil
La ejecución de los hilos en Python esta controlada por el gil (global interpreter loock) de forma que sólo un hilo puede ejecutarse a la vez, independientemente del número de procesadores con el que cuente la máquina. Esto posibilita que el escribir extensiones en c para Python sea mucho más sencillo, pero tiene la desventaja de limitar mucho el rendimiento, por lo que a pesar de todo, en Python, en ocasiones nos puede interesar más utilizar procesos que hilos, que no sufren de esta limitación.

Cada cierto número de instrucciones de bytecode la máquina virtual para la ejecución del hilo y elige otro de entre los que estaban esperando.

Por defecto el cambio de hilo se realiza cada 10 instrucciones de bytecode, aunque se puede modificar mediante la función Sys, setcheckinterval. También se cambia de hilo cuando el hilo se pone a dormir con time, slep o cuando comienza una operación de entrada/salida, las cuales pueden tardar mucho en finalizar, y por lo tanto, de no realizar el cambio, tendríamos a la CPU demasiado tiempo sin trabajar esperando a que la operación de e/s terminara.

Para minimizar un poco el efecto del gil en el rendimiento de nuestra.

Aplicación es conveniente llamar al intérprete con el flag -o, lo que hará que se genere un bytecode optimizado con menos instrucciones y, por lo tanto, menos cambios de contexto. También podemos plantearnos el utilizar procesos en lugar de hilos, como ya comentamos, utilizando, por ejemplo, el módulo processing, escribir el código en el que el rendimiento sea crítico en una extensión en c o utilizar ironpython o jython, que carecen de gil.
threads en Python
El trabajo con hilos se lleva a cabo en Python mediante el módulo hilo. Este módulo es opcional y dependiente de la plataforma, y puede ser necesario, aunque no es común, recompilar el intérprete para añadir el soporte de hilos.

Además, de hilo, también contamos con el módulo hiloing que se apoya en el primero para proporcionarnos una Api de más alto nivel, más completa, y orientada a objetos. El módulo hiloing se basa ligeramente en el modelo de hilos de java.

El módulo hiloing contiene una clase thread que debemos extender para crear nuestros propios hilos de ejecución. El método run contendrá el código que queremos que ejecute el hilo. Si queremos especificar nuestro propio constructor, este deberá llamar a hiloing. Thread.__init__(self) para inicializar el objeto correctamente.

Import hiloing.

Class mithread(threading. Thread):
Def __init__(self, num):
Threading. Thread.__init__(self)
Self, num = num.

Def run(self):
Print soy el hilo, self, num.

Para que el hilo comience a ejecutar su código basta con crear una instancia de la clase que acabamos de definir y llamar a su método start. El código del hilo principal y el del que acabamos de crear se ejecutaran de forma concurrente.

Print soy el hilo principal
For I in range (0, 10):
T = mithread(i)
T, start()
T.join().

El método join se utiliza para que el hilo que ejecuta la llamada se bloque hasta que finalice el hilo sobre el que se llama. En este caso se utiliza para que el hilo principal no termine su ejecución antes que los hijos, lo cual podría resultar en algunas plataformas en la terminación de los hijos antes de finalizar su ejecución. El método join puede tomar como parámetro un número en coma flotante indicando el número máximo de segundos a esperar.

Si se intenta llamar al método start para una instancia que ya se está ejecutando, obtendremos una excepción.

La forma recomendada de crear nuevos hilos de ejecución consiste en extender la clase thread, como hemos visto, aunque también es posible crear una instancia de thread directamente, e indicar como parámetros del constructor una clase ejecutable (una clase con el método especial __call__) o una función a ejecutar, y los argumentos en una tupla (parámetro args) o un diccionario (parámetro kwargs).

Import hiloing.

Def imprime (num):
Print soy el hilo, num.

Print soy el hilo principal
For I in range (0, 10):
T = hiloing. Thread(target=imprime, args=(i,))
T, start().

Además, de los parámetros target, args y kwargs también podemos pasar al constructor un parámetro de tipo cadena name con el nombre que queremos que tome el hilo (el hilo tendrá un nombre predeterminado, aunque no lo especifiquemos), un parámetro de tipo booleano verbose para indicar al módulo que imprima mensajes sobre el estado de los hilos para la depuración y un parámetro group, que, por ahora no admite ningún valor, pero que en el futuro se utilizara para crear grupos de hilos y poder trabajar a nivel de grupos.

Para comprobar si un hilo sigue ejecutándose, se puede utilizar el método isalive. También podemos asignar un nombre al hilo y consultar su nombre con los métodos setname y getname, respectivamente.

Mediante la función hiloing, enumerate obtendremos una lista de los objetos thread que se están ejecutando, incluyendo el hilo principal (podemos comparar el objeto thread con la variable main_thread para comprobar si se trata del hilo principal) y con hiloing, activecount podemos consultar el número de hilos ejecutándose.

Los objetos thread también cuentan con un método setdaemon que toma un valor booleano indicando si se trata de un demonio. La utilidad de esto es que, si solo quedan hilos de tipo demonio ejecutándose, la aplicación terminara automáticamente, terminando estos hilos de forma segura.

Por último, tenemos en el módulo hiloing una clase timer que hereda de thread y cuya utilidad es la de ejecutar el código de su método run después de un período de tiempo indicado como parámetro en su constructor. También incluye un método cancel mediante el que cancelar la ejecución antes de que termine el período de espera.

Sincronización
Uno de los mayores problemas a los que tenemos que enfrentarnos al utilizar hilos es la necesidad de sincronizar el acceso a ciertos recursos por parte de los hilos. Entre los mecanismos de sincronización que tenemos disponibles en el módulo hiloing se encuentran los locks, locks rentrantes, semáforos, condiciones y eventos.

Los locks, también llamados mutex (de mutual exclusión), cierres de exclusión mutua, cierres o candados, son objetos con dos estados posibles: adquirido o libre. Cuando un hilo adquiere el candado, los demás hilos que lleguen a ese punto posteriormente y pidan adquirirlo se bloquearan hasta que el hilo que lo a adquirido libere el candado, momento en el cual podrá entrar otro hilo.

El candado se representa mediante la clase loock. Para adquirir el candado se utiliza el método acquire del objeto, al que se le puede pasar un booleano para indicar si queremos esperar a que se libere (true) o no (false). Si indicamos que no queremos esperar, el método devolverá true o false dependiendo de si se adquirió o no el candado, respectivamente. Por defecto, si no se indica nada, el hilo se bloquea indefinidamente.

Para liberar el candado una vez hemos terminado de ejecutar el bloque de código en el que pudiera producirse un problema de concurrencia, se utiliza el método release.

Lista = []
Lok = hiloing. Loock()
Def añadir(obj):
Lock, acquire ()
Lista, append(obj)
Lock, release ()
Def obtener():
Lock, acquire ()
Obj = lista, pop()
Lock, release ()
Return obj.

La clase rlok funciona de forma similar a loock, pero en este caso el candado puede ser adquirido por el mismo hilo varias veces, y no quedará liberado hasta que el hilo llame a reléase tantas veces como llamó a acquire. Como en loock, y como en todas las primitivas de sincronización que veremos a continuación, es posible indicar a acquire si queremos que se bloque o no.

Los semáforos son otra clase de candados. La clase correspondiente, semaphore, también cuenta con métodos acquire y release, pero se diferencia de un lok normal en que el constructor de semaphore puede tomar como parámetro opcional un entero value indicando el número máximo de hilos que pueden acceder a la vez a la sección de código crítico. Si no se indica nada permite el acceso a un solo hilo.

Cuando un hilo llama a acquire, la variable que indica el número de hilos que pueden adquirir el semáforo disminuye en 1, porque hemos permitido entrar en la sección de código crítico a un hilo más. Cuando un hilo llama a release, la variable aumenta en 1.

No es hasta que esta variable del semáforo es 0, que llamar a acquire producirá un bloqueo en el hilo que realizó la petición, a la espera de que algún otro hilo llame a reléase para liberar su plaza.

Es importante destacar que el valor inicial de la variable tal como lo pasamos en el constructor, no es un límite máximo, sino que múltiples llamadas a reléase pueden hacer que el valor de la variable sea mayor que su valor original. Si no es esto lo que queremos, podemos utilizar la clase boundedsemaphore en cuyo caso, ahora sí, se consideraría un error llamar a reléase demasiadas veces, y se lanzaría una excepción de tipo valueerror de superarse el valor inicial.

Podríamos utilizar los semáforos, por ejemplo, en un pequeño programa en el que múltiples hilos descargaran datos de una url, de forma que pudiéramos limitar el número de conexiones a realizar al sitio web para no bombardear el sitio con cientos de peticiones concurrentes.

Semáforo = hiloing. Semaphore (4)
Def descargar(url):
Semáforo, acquire ()
Urllib, urlretrieve (url)
Semáforo, release ().

Las condiciones (clase condition) son de utilidad para hacer que los hilos sólo puedan entrar en la sección crítica de darse una cierta condición o evento. Para esto utilizan un lok pasado como parámetro, o crean un objeto rlok automáticamente si no se pasa ningún parámetro al constructor.

Son especialmente adecuadas para el clásico problema de productor-consumidor. La clase cuenta con métodos acquire y release, que llamaran a los métodos correspondientes del candado asociado. También tenemos métodos wait, notify y notifyall.

El método wait debe llamarse después de haber adquirido el candado con acquire. Este método libera el candado y bloquea al hilo hasta que una llamada a notify o notifyall en otro hilo le indican que se ha cumplido la condición por la que esperaba. El hilo que informa a los demás de que se ha producido la condición, también debe llamar a acquire antes de llamar a notify o notifyall.

Al llamar a notify, se informa del evento a un solo hilo, y por tanto se despierta un solo hilo. Al llamar a notifyall se despiertan todos los hilos que esperaban a la condición.

Tanto el hilo que notifica como los que son notificados tienen que terminar liberando el look con release.

Lista = []
Cond = hiloing. Condition()
Def consumir():
Cond, acquire ()
Cond.wait()
Obj = lista, pop()
Cond, release ()
Return obj.

Def producir(obj):
Cond, acquire ()
Lista, append(obj)
Cond, notify()
Cond, release ().

Los eventos, implementados mediante al clase event, son un Wrapper.

Por encima de condition y sirven principalmente para coordinar hilos mediante señales que indican que se ha producido un evento. Los eventos nos abstraen del hecho de que estemos utilizando un lok por debajo, por lo que carecen de métodos acquire y release.

El hilo que debe esperar el evento llama al método wait y se bloquea, opcionalmente pasando como parámetro un número en coma flotante indicando el número máximo de segundos a esperar. Otro hilo, cuando ocurre el evento, manda la señal a los hilos bloqueados a la espera de dicho evento utilizando el método set. Los hilos que estaban esperando se desbloquean una vez recibida la señal. El flag que determina si se ha producido el evento se puede volver a establecer a falos usando clear.

Como vemos los eventos son muy similares a las condiciones, a excepción de que se desbloquean todos los hilos que esperaban el evento y que no tenemos que llamar a acquire y release.

Import hiloing, time.

Class mithread(threading. Thread):
Def __init__(self, evento):
Threading. Thread.__init__(self)
Self, evento = evento.

Def run(self):
Print self, getname (), esperando al evento
Self, evento.wait()
Print self, getname (), termina la espera
Evento = hiloing. Event()
T1 = mithread(evento)
T1.start()
T2 = mithread(evento)
T2.start()
# esperamos un poco.

Time, slep(5)
Evento, set().

Por último, un pequeño extra. Si sois usuarios de java sin duda estaréis echando en falta una palabra clave syncronized para hacer que sólo un hilo pueda acceder al método sobre el que se utiliza a la vez. Una construcción común es el uso de un decorador para implementar esta funcionalidad usando un loock. Sería algo así.

Def synchronized(Lock):
Def Dec(f):
Def func_dec(*args, **kwargs):
Lock, acquire ()
Try:
Return f(*args, **kwargs)
Finally:
Lock, release ()
Return func_dec.

Return Dec.

Class mythread(threading. Thread):
@synchronized(mi_lock)
Def run(self):
Print método sincronizado.

Datos globales independientes
Como ya hemos comentado los hilos comparten las variables globales. Sin embargo, pueden existir situaciones en las que queramos utilizar variables globales, pero que estas variables se comporten como si fueran locales a un solo hilo. Es decir, que cada uno de los hilos tengan valores distintos independientes, y que los cambios de un determinado hilo sobre el valor no se vean reflejados en las copias de los demás hilos.

Para lograr este comportamiento se puede utilizar la clase hiloing, local, que crea un almacén de datos locales. Primero debemos crear una instancia de la clase, o de una subclase, para después almacenar y obtener los valores a través de parámetros de la clase.

Datos_locales = hiloing, local()
Datos_locales, mi_var = mortal kombat
Print datos_locales, mi_var.

Fijémonos en el siguiente código, por ejemplo. Para el hilo principal el objeto local tiene un atributo VAR, y por lo tanto el print imprime su valor sin problemas. Sin embargo, para el hilo te ese atributo no existe, y por lo tanto lanza una excepción.

Local = hiloing, local()
Def f():
Print local, VAR.

Local, VAR = mortal kombat
T = hiloing. Thread(target=f)
Print local, VAR.

T, start()
T.join().

compartir información
Para compartir información entre los hilos de forma sencilla podemos utilizar la clase queue. Queue, que implementa una cola (una estructura de datos de tipo fifo) con soporte multihilo. Esta clase utiliza las primitivas de hiloing para ahorrarnos tener que sincronizar el acceso a los datos nosotros mismos.

El constructor de queue toma un parámetro opcional indicando el tamaño máximo de la cola. Si no se indica ningún valor no hay límite de tamaño.

Para añadir un elemento a la cola se utiliza el método put(item), para obtener el siguiente elemento, get(). Ambos métodos tienen un parámetro booleano opcional block indica si queremos que se espere hasta que haya algún elemento en la cola para poder devolverlo o hasta que la cola deje de estar llena para poder introducirlo.

También existe un parámetro opcional timeout que indica, en segundos, el tiempo máximo a esperar. Si el timeout acaba sin poder haber realizado la operación debido a que la cola estaba llena o vacía, o bien si block era false, se lanzara una excepción de tipo queue. Full o queue. Empty, respectivamente.

Con qsize obtenemos el tamaño de la cola y con empty() y full() podemos comprobar si esta vacía o llena.

Que = queue. Queue ()
Class mithread(threading. Thread):
Def __init__(self, q):
Self, que = que.

Threading. Thread.__init__(self)
Def run(self):
While true:
Try:
Obj = que, get(false)
Except queue. Empty:
Print fin
Break.

Print obj.

For I in range (10):
Q, put(i)
T = mithread(q)
T, start()
T.join().

[3dpoder]

serialización de objetos
.Algunas veces tenemos la necesidad de guardar un objeto a disco para poder recuperarlo más tarde, o puede que nos sea necesario mandar un objeto a través de la red, a otro programa en Python ejecutándose en otra máquina.

Al proceso de transformar el estado de un objeto en un formato que se pueda almacenar, recuperar y transportar se le conoce con el nombre de serialización o marshalling.

En Python tenemos varios módulos que nos facilitan esta tarea, como marshal, pickle, cpickle y shelve.

El módulo marshal es el más básico y el más primitivo de los tres, y es que, de hecho, su propósito principal y su razón de ser no es el de serializar objetos, sino trabajar con bytecode Python (archivos.pyc).

Marshal sólo permite serializar objetos simples (la mayoría de los tipos incluidos por defecto en Python), y no proporciona ningún tipo de mecanismo de seguridad ni comprobaciones frente a datos corruptos o mal formateados. Es más, el formato utilizado para guardar el bytecode (y por tanto el formato utilizado para guardar los objetos con marshal) puede cambiar entre versiones, por lo que no es adecuando para almacenar datos de larga duración.

Pickle, por su parte, permite serializar casi cualquier objeto (objetos de tipos definidos por el usuario, colecciones que contienen colecciones, etc) y cuenta con algunos mecanismos de seguridad básicos. Sin embargo, al ser más complejo que marshal y, sobre todo, al estar escrito en Python en lugar de en c, como marshal, también es mucho más lento.

La solución, si la velocidad de la serialización es importante para nuestra aplicación, es utilizar cpickle, que no es más que es una implementación en c de pickle, cpickle es hasta 1000 veces más rápido que pickle, y prácticamente igual de rápido que marshal.

Si intentamos importar cpickle y se produce un error por algún motivo, se lanzara una excepción de tipo importerror. Para utilizar cpickle si está disponible y pickle en caso contrario, podríamos usar un código similar al siguiente.

Try:
Import cpickle as pickle.

Except importerror:
Import pickle.

As en un import sirve para importar el elemento seleccionado utilizando otro nombre indicado, en lugar de su nombre.

La forma más sencilla de serializar un objeto usando pickle es mediante una llamada a la función dump pasando como argumento el objeto a serializar y un objeto archivo en el que guardarlo (o cualquier otro tipo de objeto similar a un archivo, siempre que ofrezca métodos read, realine y write).

Try:
Import cpickle as pickle.

Except importerror:
Import pickle.

Fichero = file (datos, dat, w)
Animales = [piton, mono, camello]
Pickle, dump(animales, fichero)
Fichero, close ().

La función dump también tiene un parámetro opcional protocol que indica el protocolo a utilizar al guardar. Por defecto su valor es 0, que utiliza formato texto y es el menos eficiente. El protocolo 1 es más eficiente que el 0, pero menos que el 2. Tanto el protocolo 1 como el 2 utilizan un formato binario para guardar los datos.

Try:
Import cpickle as pickle.

Except importerror:
Import pickle.

Fichero = file (datos, dat, w)
Animales = [piton, mono, camello]
Pickle, dump(animales, fichero, 2)
Fichero, close ().

Para volver a cargar un objeto serializado se utiliza la función load, a la que se le pasa el archivo en el que se guardó.

Try:
Import cpickle as pickle.

Except importerror:
Import pickle.

Fichero = file (datos, dat, w)
Animales = [piton, mono, camello]
Pickle, dump(animales, fichero)
Fichero, close ()
Fichero = file (datos, dat)
Animales2 = pickle, load(fichero)
Print animales2.

Supongamos ahora que queremos almacenar un par de listas en un fichero. Esto sería tan sencillo como llamar una vez a dump por cada lista, y llamar después una vez a load por cada lista.

Fichero = file (datos, dat, w)
Animales = [piton, mono, camello]
Lenguajes = [Python, mono, perl]
Pickle, dump(animales, fichero)
Pickle, dump(lenguajes, fichero)
Fichero = file (datos, dat)
Animales2 = pickle, load(fichero)
Lenguajes2 = pickle, load(fichero)
Print animales2
Print lenguajes2.

Pero, ¿y si hubiéramos guardado 30 objetos y quisiéramos acceder al último de ellos? ¿o si no recordaramos en que posición lo habíamos guardado? El módulo shelve extiende pickle / cpickle para proporcionar una forma de realizar la serialización más clara y sencilla, en la que podemos acceder a la versión serializada de un objeto mediante una cadena asociada, a través de una estructura parecida a un diccionario.

La única función que necesitamos conocer del módulo shelve es open, que cuenta con un parámetro filename mediante el que indicar la ruta a un archivo en el que guardar los objetos (en realidad se puede crear más de un archivo, con nombres basados en filename, pero esto es transparente al usuario).

La función open también cuenta con un parámetro opcional protocol, con el que especificar el protocolo que queremos que utilice pickle por debajo.

Como resultado de la llamada a open obtenemos un objeto shelf, con el que podemos trabajar como si de un diccionario normal se tratase (a excepción de que las claves sólo pueden ser cadenas) para almacenar y recuperar nuestros objetos.

Como un diccionario cualquiera la clase shelf cuenta con métodos get, has_key, Items, keys, values.

Una vez hayamos terminado de trabajar con el objeto shelf, lo cerraremos utilizando el método close.

Import shelve.

Animales = [piton, mono, camello]
Lenguajes = [Python, mono, perl]
Shelf = shelve, open(datos, dat)
Shelf[primera] = animales.

Shelf[segunda] = lenguajes.

Print shelf[segunda]
Shelf, close ().

[3dpoder]

bases de datos
.Existen problemas para los que guardar nuestros datos en ficheros de texto plano, en archivos xml, o mediante serialización con Pickle o Shelve pueden ser soluciones poco convenientes. En ocasiones no queda más remedio que recurrir a las bases de datos, ya sea por cuestiones de escalabilidad, de interoperabilidad, de coherencia, de seguridad, de confidencialidad, etc.

A lo largo de este capítulo aprenderemos a trabajar con bases de datos en Python. Sin embargo, se asumen una serie de conocimientos básicos, como puede ser el manejo elemental de sql. Si este no es el caso, existen miles de recursos a disposición del lector en internet para introducirse en el manejo de bases de datos.
db Api
Existen cientos de bases de datos en el mercado, tanto comerciales como gratuitas. También existen decenas de módulos distintos para trabajar con dichas bases de datos en Python, lo qué significa decenas de apis distintas por aprender.

En Python, como en otros lenguajes como java con JDBC, existe una propuesta de Api estándar para el manejo de bases de datos, de forma que el código sea prácticamente igual independientemente de la base de datos que estemos utilizando por debajo. Esta especificación recibe el nombre de Python database Api o db-api y se recoge en el Pep 249 (http://www.Python.org/dev/peps/Pep-0249/).

Db-api se encuentra en estos momentos en su versión 2.0, y existen implementaciones para las bases de datos relacionales más conocidas, así como para algunas bases de datos no relacionales.

A lo largo de este capítulo utilizaremos la base de datos SQLite para los ejemplos, ya que no se necesita instalar y ejecutar un proceso servidor independiente con el que se comunique el programa, sino que se trata de una librería en c que se integra con la aplicación y que viene incluida con Python por defecto desde la versión 2.5. Desde la misma versión Python también incorpora un módulo compatible con esta base de datos que sigue la especificación de db Api 2.0: sqlite 3, por lo que no necesitaremos ningún tipo de configuración extra.

Nada impide al lector, no obstante, instalar y utilizar cualquier otra base de datos, como mysql, con la cual podemos trabajar a través del driver compatible con db Api 2.0 mysqldb (http://mysql-Python.sourceforge.net/).
variables globales
Antes de comenzar a trabajar con sqlite3, vamos a consultar algunos datos interesantes sobre el módulo. Todos los drivers compatibles con db-api 2.0 deben tener 3 variables globales que los describen. A saber:

• apilevel : una cadena con la versión de db Api que utiliza. Actualmente sólo puede tomar como valor 1.0 o 2.0. Si la variable no existe se asume que es 1.0.
• threadsafety : se trata de un entero de 0 a 3 que describe lo seguro que es el módulo para el uso con hilos. Si es 0 no se puede compartir el módulo entre hilos sin utilizar algún tipo de mecanismo de sincronización, si es 1, pueden compartir el módulo, pero no las conexiones, si es 2, módulos y conexiones, pero no cursores y, por último, si es 3, es totalmente hilo-safe.
• paramstyle: informa sobre la sintaxis a utilizar para insertar valores en la consulta sql de forma dinámica.

Qmarkɣɣ: interrogaciones, sql = select all from te where valor=?
Numericɣɣ: un número indicando la posición, sql = select all from te where valor=:1.

Namedɣɣ: el nombre del valor.

Formatɣɣ: especificadores de formato similares a los del printf de c.

Sql = select all from te where valor=%s.

Pyformatɣɣ: similar al anterior, pero con las extensiones de Python.

Sql = select all from te where valor=%(valor).

Veamos los valores correspondientes a sqlite3.

>>> import sqlite3 as dbapi.
>>> print dbapi, apilevel.
2.0
>>> print dbapi, hilosafety.
1
>>> print dbapi, paramstyle.

Qmark.

excepciones
A continuación podéis encontrar la jerarquía de excepciones que deben proporcionar los módulos, junto con una descripción de cada excepción, a modo de referencia.

Standarderror.
-|__warning.
-|__error.
-|__interfaceerror.
-|__databaseerror.
-|__dataerror.
-|__operationalerror.
-|__integrityerror.
-|__internalerror.
-|__programmingerror.
-|__notsupportederror.

Standarderroro : super clase para todas las excepciones de db Api.
Warningo : excepción que se lanza para avisos importantes.

Erroro : super clase de los errores.

Interfaceerroro : errores relacionados con la interfaz de la base de datos, y no con la base de datos en sí.

Databaseerroro : errores relacionados con la base de datos.

Dataerroro : errores relacionados con los datos, como una división entre cero.

Operationalerroro : errores relacionados con el funcionamiento de la base de datos, como una desconexión inesperada.

Integrityerroro : errores relacionados con la integridad referencial.

Internalerroro : error interno de la base de datos.

Programmingerroro : errores de programación, como errores en el código sql.

Notsupportederroro : excepción que se lanza cuando se solicita un método que no está soportado por la base de datos.
uso básico de db-api
Pasemos ahora a ver cómo trabajar con nuestra base de datos a través de db-api.

Lo primero que tendremos que hacer es realizar una conexión con el servidor de la base de datos. Esto se hace mediante la función connect, cuyos parámetros no están estandarizados y dependen de la base de datos a la que estemos conectándonos.

En el caso de sqlite3 sólo necesitamos pasar como parámetro una cadena con la ruta al archivo en el que guardar los datos de la base de datos, o bien la cadena :memory: para utilizar la memoria Ram en lugar de un fichero en disco.

Por otro lado, en el caso de mysqldb, connect toma como parámetros la máquina en la que corre el servidor (host), el puerto (port), nombre de usuario con el que autenticarse (user), contraseña (password) y base de datos a la que conectarnos de entre las que se encuentran en nuestro sgbd (db).

La función connect devuelve un objeto de tipo connection que representa la conexión con el servidor.

>>> base de datos = dbapi, connect(base de datos, dat)
>>> print base de datos.
sqlite3. Connection object at 0x00a71da0>.

Las distintas operación que podemos realizar con la base de datos se realizan a través de un objeto cursor. Para crear este objeto se utiliza el método cursor() del objeto connection.

C = base de datos, cursor().

Las operación se ejecutan a través del método execute de cursor, pasando como parámetro una cadena con el código sql a ejecutar.

Como ejemplo creemos una nueva tabla empleados en la base de datos.

C, execute (create table empleados (dni text, nombre text, departamento text)).

Y a continuación, insertemos una tupla en nuestra nueva tabla.

C, execute (insert into empleados values (12345678-a, Manuel gil, contabilidad)).

Si nuestra base de datos soporta transacciones, si estas están activadas, y si la característica de auto-commit esta desactivada, será necesario llamar al método commit de la conexión para que se lleven a cabo las operación definidas en la transacción.

Si en estas circunstancias utilizáramos una herramienta externa para comprobar el contenido de nuestra base de datos sin hacer primero el commit nos encontraríamos entonces con una base de datos vacía.

Si comprobamos el contenido de la base de datos desde Python, sin cerrar el cursor ni la conexión, recibiríamos el resultado del contexto de la transacción, por lo que parecería que se han llevado a cabo los cambios, aunque no es así, y los cambios sólo se aplican, como comentamos, al llamar a commit.

Para bases de datos que no soporten transacciones el estándar dicta.

Que debe proporcionarse un método commit con implementación vacía, por lo que no es mala idea llamar siempre a commit, aunque no sea necesario para poder cambiar de sistema de base de datos con solo modificar la línea del import.

Si nuestra base de datos soporta la característica de rollbak también podemos cancelar la transacción actual con.

Bbdd, rollback().

Si la base de datos no soporta rollbak llamar a este método producirá una excepción.

Veamos ahora un ejemplo completo de uso.

Import sqlite3 as dbapi.

Bbdd = dbapi, connect(base de datos, dat)
Cursor = base de datos, cursor()
Cursor, execute (create table empleados (dni text, nombre text, departamento text))
Cursor, execute (insert into empleados.

Values (12345678-a, Manuel gil, contabilidad))
Bbdd, commit()
Cursor, execute (select * from empleados.
Where departamento=contabilidad)
For tupla in cursor, fetchall():
Print tupla.

Como vemos, para realizar consultas a la base de datos también se utiliza execute. Para consultar las tuplas resultantes de la sentencia sql se puede llamar a los métodos de cursor fetchone, fetchmany o fetchall o usar el objeto cursor como un iterador.

Cursor, execute (select * from empleados.
Where departamento=contabilidad)
For resultado in cursor:
Print tupla.

El método fetchone devuelve la siguiente tupla del conjunto resultado o none cuando no existen más tuplas, fetchmany devuelve el número de tuplas indicado por el entero pasado como parámetro o bien el número indicado por el atributo cursor, arraysize si no se pasa ningún parámetro (cursor, arraysize vale 1 por defecto) y fetchall devuelve un objeto iterable con todas las tuplas.

A la hora de trabajar con selects u otros tipos de sentencias sql es importante tener en cuenta que no deberían usarse los métodos de cadena habituales para construir las sentencias, dado que esto nos haría vulnerables a ataques de inyección sql, sino que en su lugar debe usarse la característica de sustitución de parámetros de db Api.

Supongamos que estamos desarrollando una aplicación web con Python para un banco y que se pudiera consultar una lista de sucursales del banco en una ciudad determinada con una url de la forma http://www.mibanco.com/sucursalesiciudad=Madrid.

Podríamos tener una consulta como esta.

Cursor, execute (select * from sucursales.
Where ciudad= + ciudad + ).

A primera vista podría parecer que no existe ningún problema: no hacemos más que obtener las sucursales que se encuentren en la ciudad indicada por la variable ciudad. Pero, ¿Qué ocurriría si un usuario malintencionado accediera a una url como http://www.mibanco.com/sucursalesíciudad=Madrid;select * from contrasenyas?
Como no se realiza ninguna validacción sobre los valores que puede contener la variable ciudad, sería sencillo que alguien pudiera hacerse con el control total de la aplicación.

Lo correcto sería, como decíamos, utilizar la característica de sustitución de parámetros de db Api. El valor de paramstyle para el módulo sqlite3 era qmark. Esto significa que debemos escribir un signo de interrogación en el lugar en el que queramos insertar el valor, y basta pasar un segundo parámetro a execute en forma de secuencia o mapping con los valores a utilizar para que el módulo cree la sentencia por nosotros.

Cursor, execute (select * from sucursales.
Where ciudad=? (ciudad,)).

Por último, al final del programa se debe cerrar el cursor y la conexión.

Cursor, close ()
Bbdd, close ().

Tipos sql
En ocasiones podemos necesitar trabajar con tipos de sql, y almacenar, por ejemplo, fechas u horas usando date y time y no con cadenas. La Api de bases de datos de Python incluye una serie de constructores a utilizar para crear estos tipos. Estos son:
Date (year, month, day) : para almacenar fechas.

Time (hour, minute, second) : para almacenar horas.

Timestamp(year, month, day, hour, minute, second) : para almacenar timestamps (una fecha con su hora).

Datefromticks(ticks) : para crear una fecha a partir de un número con los segundos transcurridos desde el epoch (el 1 de enero de 1970 a las 00:00:00 gmt).

Timefromticks(ticks) : similar al anterior, para horas en lugar de fechas.

Timestampfromticks(ticks)o : similar al anterior, para timestamps, binary(string) : valor binario.
otras opciones
Por supuesto no estamos obligados a utilizar db-api, ni bases de datos relacionales. En Python existen módulos para trabajar con bases de datos orientadas a objetos, como zodb (zope object database) y motores para mapeo objeto-relacional (orm) como sqlalchemy, sqlobject o Storm.

Además, si utilizamos ironpython en lugar de cpython tenemos la posibilidad de utilizar las conexiones a bases de datos de. Net, y si utilizamos jython, las de java.

[3dpoder]

documentación.

Docstrings
En capítulos anteriores ya comentamos en varias ocasiones que todos los objetos cuentan con una variable especial __doc__ mediante la que indicar el propósito y uso del objeto. Estos son los llamados docstrings o cadenas de documentación.

A estos atributos se les puede asociar el texto correspondiente explícitamente, asignándolo al literal cadena correspondiente, como con cualquier otra variable. Sin embargo, por conveniencia, Python ofrece un mecanismo mucho más sencillo y es que, si el primer estamento de la definición del objeto es una cadena, esta se asocia a la variable __doc__ automáticamente.

Def haz_algo (arg):
Este es el docstring de la función.

Print arg.

Print haz_algo.__doc__
Haz_algo.__doc__ = este es un nuevo docstring.

Print haz_algo.__doc.

Como vemos lo interesante de estas cadenas es que, a diferencia de los comentarios normales de Python y de los comentarios de otros lenguajes, las cadenas de documentación no se eliminan del bytecode, por lo que se pueden consultar en tiempo de ejecución, usando, por ejemplo, la función help del lenguaje, o utilizando la sentencia print como en el ejemplo anterior.

>>> help(haz_algo)
Help on function haz_algo in module __main__:
Haz_algo (arg).

Este es un nuevo docstring.
pydoc
La función help, que comentamos brevemente con anterioridad, utiliza el módulo pydoc para generar la documentación de un objeto a partir de su docstring y los docstrings de sus miembros. Este módulo, incluido por defecto con Python desde la versión 2.1, se puede importar en nuestro código Python y utilizarse programáticamente, o bien se puede utilizar como una herramienta de línea de comandos que sería el equivalente a la aplicación javadoc del mundo java.

Pydoc puede mostrar la información como texto en la consola, tal como lo utiliza help, pero también puede generar archivos html como javadoc o facilitar la información a través de un pequeño servidor web incluido con el módulo.

Pydoc es muy sencillo de utilizar. Con.

Pydoc, py nombre1 [nombre2.].

Se muestra la documentación del tema, módulo, clase, paquete, función o palabra clave indicada de forma similar a la función help. Si el nombre es keywords, topics o modules se listaran las distintas palabras claves, temas y módulos respectivamente.

Si se pasa el flag -w, el script guardará la documentación en uno o varios archivos html en lugar de mostrarla por pantalla.

Pydoc, py -w nombre1 [nombre2.].

El flag -que sirve para buscar una determinada palabra en las sinopsis de todos los módulos disponibles. La sinopsis es la primera línea de la cadena de documentación.

Pydoc, py -que xml.

Con -p podemos iniciar el servidor htp en el puerto indicado.

Pydoc, py -p puerto.

Una vez hecho esto podemos acceder a la documentación de todos los módulos disponibles abriendo la página http://localhost:puerto en nuestro navegador.

Por último, mediante el flag -g podemos lanzar una interfaz gráfica para buscar documentación que utiliza el servidor htp para mostrar los resultados.

Epydoc y restructuredtext
El problema de pydoc es que es muy simple, y no permite añadir semántica o modificar estilos de la documentación. No podemos, por ejemplo, indicar que en una línea en concreto de entre las líneas de documentación de la función describe un parámetro de la función o mostrar un cierto término en cursiva.

Existen proyectos para generar documentación con funcionalidades más avanzadas como docutils, epydoc o sphinx, aunque es necesario aprender sintaxis especiales.

Docutils es un proyecto desarrollado por David godger que incluye.

Distintas herramientas para generar documentación utilizando el formato restructuredtext, un formato de texto plano creado por el mismo autor, y que es el formato más utilizado en la comunidad Python, restructuredtext se utiliza, entre otros, para la creación de los peps (Python enhancement proposals).

Sin embargo, actualmente docutils es más indicado para generar documentos a partir de archivos de texto, y no a partir de docstrings extraídos de código fuente Python, ya que el parser encargado de este trabajo dista mucho de estar terminado.

Epydoc es una de las herramientas de generación de documentación para Python más utilizadas. Además, de texto plano y de su propio formato, llamado epytext, soporta restructuredtext y sintaxis javadoc, cosa que los programadores java agradecerán.

A lo largo del resto del capítulo utilizaremos restructuredtext como lenguaje de marcado y epydoc para generar los documentos finales.

Epydoc se puede descargar desde su página web en forma de instalador exe para Windows, paquete rpm para Fedora o similares, o en archivos (*.zip) y (*.tar), (*.gz) que incluyen scripts de instalación: http://epydoc.sourceforge.net/. También se encuentra en los repositorios de varias distribuciones Linux.

Una vez hayamos instalado epydoc siguiendo el método adecuando para nuestro sistema operativo tendremos acceso a su funcionalidad a través de dos interfaz de usuario distintas: el script epydoc, que consiste en una aplicación de línea de comandos, y el script epydocgui (epydoc, pyw en Windows), que ofrece una interfaz gráfica. Además, también podemos acceder a la funcionalidad de epydoc programáticamente, como en el caso de pydoc.

Vamos a crear un pequeño módulo con un par de clases para ver primero el resultado de utilizar epydoc con docstrings de texto plano, sin ningún tipo de marcado especial.

modulo para ejemplificar el uso de epydoc.

Class persona:
Mi clase de ejemplo.

Def __init__(self, nombre):
Inicializador de la clase persona.

Self, nombre = nombre.

Self, mostrar_nombre ()
Def mostrar_nombre (self):
Imprime el nombre de la persona
Print esta es la persona %s % self, nombre.

Class empleado (persona):
Subclase de persona.

Pass.

If __name__ == __main__:
Raúl = persona (Raúl).

El formato de salida por defecto de epydoc es html. Por lo tanto, para generar la documentación en forma de documentos html bastaría escribir algo así.

Epydoc ejemplo, py.

O bien.

Epydoc -html ejemplo, py.

Para generar un archivo pdf, utilizando latex, se utilizaría el flag -pdf.

Epydoc -pdf ejemplo, py.

Si latex no está instalado o epydoc no encuentra el ejecutable no será posible generar el pdf.

También podemos indicar el nombre del proyecto y la url mediante las opciones -name y -url.

Epydoc -name ejemplo -url http://mundogek.net ejemplo, py.

E incluso añadir diagramas mostrando la clase base y subclases (-Graph classtre), las llamadas entre funciones y métodos (-Graph callgraph), clases y subclases usando notación UML (-Graph umlclasstre) o todos ellos (-Graph all).

Epydoc -Graph all ejemplo, py.

Para generar el grafo de llamadas, no obstante, es necesario generar un archivo con la información necesaria utilizando el módulo profile o el módulo hotshot e indicar el archivo resultante utilizando el flag -pstat.

Epydoc -Graph all -pstat profile, out ejemplo, py.

Veamos ahora algunas funcionalidades básicas de marcado en restructuredtext.

Para poner un texto en italica se rodea el texto con asteriscos.

*italica* -> italica.

Para ponerlo en negrita, se utilizan dos asteriscos.

**negrita** -> negrita.

Para mostrar el texto como monoespacio, por ejemplo, para mostrar código inline, se utiliza .

monoespacio -> monoespacio.

Si necesitamos utilizar cualquiera de estos caracteres especiales, se pueden escapar utilizando la barra invertida.

\* es un carácter especial -> * es un carácter especial.

Los títulos se crean añadiendo una línea de caracteres no alfanuméricos por debajo del texto, o por encima y por debajo del texto. Para crear un subtítulo basta utilizar una nueva combinación.

Título.
======
Subtitulo.
------------------
título.

Subtitulo.

Para crear una lista no ordenada se empieza cada línea con el carácter *, - o +:
* Python.
* c.
* java.

Pythono
Co
Javao.

Para crear una lista numerada se empieza la línea con el número se guido de un punto, o bien con el símbolo # para que se introduzca el número automáticamente.
1. Python.
2. C
3. Java.
1. Python.
2. C
3. Java.

Para describir propiedades de los elementos que estamos documentando se utilizan los campos o Fields. En restructuredtext los campos comienzan con :, le sigue el nombre del campo y opcionalmente sus argumentos, y se cierra de nuevo con :, para terminar con el cuerpo del campo.

Estos son algunos de los campos que soporta epydoc:



Para que epydoc sepa que utilizamos restructuredtext es necesario indicarlo mediante una variable __docformat__ en el código, o bien mediante la opción -docformat de línea de comandos. Las opciones posibles son epytext, plaintext, restructuredtext o javadoc.

Veamos un ejemplo con campos.

modulo para ejemplificar el uso de *epydoc*.
:author: Raúl González.
:versión: 0.1
_docformat__ = restructuredtext
Class persona:
Modela una persona.

Def __init__(self, nombre, edad):
Inicializador de la clase `persona`.
:param nombre: nombre de la persona.
:param edad: edad de la persona
Self, nombre = nombre.

Self, edad = edad.

Self, mostrar_nombre ()
Def mostrar_nombre (self):
Imprime el nombre de la persona
Print esta es la persona %s % self, nombre.

Class empleado (persona):
Subclase de `persona` correspondiente a las personas.

Que trabajan para la organizacion.
:todo: escribir implementación.

Pass.

If __name__ == __main__:
Juan = persona (Juan, 26).

Restructuredtext también soporta un segundo tipo de campos en el que el cuerpo del campo es una lista. De esta forma podemos, por ejemplo, describir todos los parámetros de una función o método con un solo campo arameters:, en lugar de con un campo :param: para cada parámetro.

Class persona:
Modela una persona.

Def __init__(self, nombre, edad):
Inicializador de la clase `persona`.
:parameters:
- `nombre`: nombre de la persona.
- `edad`: edad de la persona.

Self, nombre = nombre.

Self, edad = edad.

Self, mostrar_nombre ().

Otros campos que admiten listas son :exceptions: para indicar varias excepciones (:except, :variables: para comentar varias variables (:VAR o :ivariables: para comentar varias instancias (:ivar.
.

-- IMÁGENES ADJUNTAS --

[3dpoder]

pruebas
.Para asegurar en la medida de lo posible el correcto funcionamiento y la calidad del software se suelen utilizar distintos tipos de pruebas, como pueden ser las pruebas unitarias, las pruebas de integración, o las pruebas de regresión.

A lo largo de este capítulo nos centraremos en las pruebas unitarias, mediante las que se comprueba el correcto funcionamiento de las unidades lógicas en las que se divide el programa, sin tener en cuenta la interrelación con otras unidades.

La solución más extendida para las pruebas unitarias en el mundo Python es unittest, a menudo combinado con doctest para pruebas más sencillas. Ambos módulos están incluidos en la librería estándar de Python.
doctest
Como es de suponer por el nombre del módulo, doctest permite combinar las pruebas con la documentación. Esta idea de utilizar las pruebas unitarias para probar el código y también a modo de documentación permite realizar pruebas de forma muy sencilla, propicia el que las pruebas se mantengan actualizadas, y sirve a modo de ejemplo de uso del código y como ayuda para entender su propósito.

Cuando doctest encuentra una línea en la documentación que comienza con >>> se asume que lo que le sigue es código Python a ejecutar, y que la respuesta esperada se encuentra en la línea o líneas siguientes, sin >>>. El texto de la prueba termina cuando se encuentra una línea en blanco, o cuando se llega al final de la cadena de documentación.

Tomemos como ejemplo la siguiente función, que devuelve una lista con los cuadrados de todos los números que componen la lista pasada como parámetro.

Def cuadrados(lista):
Calcula el cuadrado de los números de una lista
Return [n ** 2 for n in lista].

Podríamos crear una prueba como la siguiente, en la que comprobamos que el resultado al pasar la lista [0, 1, 2, 3] es el que esperábamos.

Def cuadrados(lista):
Calcula el cuadrado de los números de una lista.
>>> l = [0, 1, 2, 3]
>>> cuadrados(l)
[0, 1, 4, 9]
Return [n ** 2 for n in lista].

Lo que hacemos en este ejemplo es indicar a doctest que cree un lista l con valor [0, 1, 2, 3], que llame a continuación a la función cuadrados con l como argumento, y que compruebe que el resultado devuelto sea igual a [0, 1, 4, 9].

Para ejecutar las pruebas se utiliza la función testmod del módulo, a la que se le puede pasar opcionalmente el nombre de un módulo a evaluar (parámetro name). En el caso de que no se indique ningún argumento, como en este caso, se evalúa el módulo actual.

Def cuadrados(lista):
Calcula el cuadrado de los números de una lista.
>>> l = [0, 1, 2, 3]
>>> cuadrados(l)
[0, 1, 4, 9]
Return [n ** 2 for n in lista]
Def _test():
Import doctest.

Doctest, testmod()
If __name__ == __main__:
Test().

En el caso de que el código no pase alguna de las pruebas que hemos definido, doctest mostrara el resultado obtenido y el resultado esperado. En caso contrario, si todo es correcto, no se mostrara ningún mensaje, a menos que añadamos la opción -v al llamar al script o el parámetro verbose=true a la función tesmod, en cuyo caso se mostraran todas las pruebas ejecutadas, independientemente de si se ejecutaron con éxito.

Este sería el aspecto de la salida de doctest utilizando el parámetro -v.

Trying:
L = [0, 1, 2, 3]
Expecting nothing.

Ok.

Trying:
Cuadrados(l)
Expecting:
[0, 1, 4, 9]
Ok.
2 Items had no tests:
_main__
_main__._test.
1 Items passed all tests:
2 tests in __main__.cuadrados.
2 tests in 3 Items.
2 passed and 0 failed, test passed.

Ahora vamos a introducir un error en el código de la función para ver el aspecto de un mensaje de error de doctest. Supongamos, por ejemplo, que hubiéramos escrito un operador de multiplicación (*) en lugar de uno de exponenciación (**).

Def cuadrados(lista):
Calcula el cuadrado de los números de una lista.
>>> l = [0, 1, 2, 3]
>>> cuadrados(l)
[0, 1, 4, 9]
Return [n * 2 for n in lista]
Def _test():
Import doctest.

Doctest, testmod()
If __name__ == __main__:
Test().

Obtendríamos algo parecido a esto.

************************************************** *******
File ejemplo, py, line 5, in __main__.cuadrados.

Failed example:
Cuadrados(l)
Expected:
[0, 1, 4, 9]
Got:
[0, 2, 4, 6]
************************************************** *******
1 Items had failures:
1 of 2 in __main__.cuadrados.
***test failed*** 1 failures.

Como vemos, el mensaje nos indica que ha fallado la prueba de la línea 5, al llamar a cuadrados(l), cuyo resultado debería ser [0, 1, 4, 9], y sin embargo, obtuvimos [0, 2, 4, 6].

Veamos por último cómo utilizar sentencias anidadas para hacer cosas un poco más complicadas con doctest. En el ejemplo siguiente nuestra función calcula el cuadrado de un único número pasado como parámetro, y diseñamos una prueba que compruebe que el resultado es el adecuando para varias llamadas con distintos valores. Las sentencias anidadas comienzan con . en lugar de >>>.

Def cuadrado (num):
Calcula el cuadrado de un número.
>>> l = [0, 1, 2, 3]
>>> for n in l:
, cuadrado (n)
[0, 1, 4, 9]
Return num ** 2
Def _test():
Import doctest.

Doctest, testmod()
If __name__ == __main__:
Test().

unittest / pyunit
Unittest, también llamado pyunit, forma parte de una familia de herramientas conocida colectivamente como xunit, un conjunto de frameworks basados en el software sunit para smalltalk, creado por kent Beck, uno de los padres de la extreme programming. Otros ejemplos de herramientas que forman parte de esta familia son junit para java, creada por el propio kent bek junto a Erich gamma, o nunit, para Net.

El uso de unittest es muy sencillo. Para cada grupo de pruebas tenemos que crear una clase que herede de unittest. Testcase, y añadir una serie de métodos que comiencen con test, que serán cada una de las pruebas que queremos ejecutar dentro de esa batería de pruebas.

Para ejecutar las pruebas, basta llamar a la función main() del módulo, con lo que se ejecutaran todos los métodos cuyo nombre comience con test, en orden alfanumérico. Al ejecutar cada una de las pruebas el resultado puede ser:
Ok : la prueba ha pasado con éxito.

Fail : la prueba no ha pasado con éxito. Se lanza una excepción assertionerror para indicarlo.

Error : al ejecutar la prueba se lanzó una excepción distinta de assertionerror.

En el siguiente ejemplo, dado que el método que modela nuestra prueba no lanza ninguna excepción, la prueba pasaría con éxito.

Import unittest.

Class ejemplopruebas(unittest. Testcase):
Def test(self):
Pass.

If __name__ == __main__:
Unittest, main().

En este otro, sin embargo, fallaría.

Import unittest.

Class ejemplopruebas(unittest. Testcase):
Def test(self):
Raise assertionerror()
If __name__ == __main__:
Unittest, main().

Nada nos impide utilizar cláusulas if para evaluar las condiciones que nos interesen y lanzar una excepción de tipo assertionerror cuando no sea así, pero la clase testcase cuenta con varios métodos que nos pueden facilitar la tarea de realizar comprobaciones sencillas. Son los siguientes:
Assertalmostequal(first, second, places=7, msg=none)o : comprueba que los objetos pasados como parámetros sean iguales hasta el séptimo decimal (o el número de decimales indicado por places).

Assertequal(first, second, msg=none)o : comprueba que los objetos pasados como parámetros sean iguales, assertfalse (expr, msg=none)o : comprueba que la expresión sea falsa.

Assertnotalmostequal(first, second, places=7, msg=none)o : comprueba que los objetos pasados como parámetros no sean iguales hasta el séptimo decimal (o hasta el número de decimales indicado por places).

Assertnotequal(first, second, msg=none)o : comprueba que los objetos pasados como parámetros no sean iguales.

Assertraises(excclass, callábleobj, *args, **kwargs)o : comprueba que al llamar al objeto callábleobj con los parámetros.

Definidos por *args y **kwargs se lanza una excepción de tipo excclass, asserttrue (expr, msg=none)o : comprueba que la expresión sea cierta.

Assert_(expr, msg=none)o : comprueba que la expresión sea cierta, fail(msg=none)o : falla inmediatamente.

Failif(expr, msg=none)o : falla si la expresión es cierta, failifalmostequal(first, second, places=7, msg=none)o : falla si los objetos pasados como parámetros son iguales hasta el séptimo.

Decimal (o hasta el número de decimales indicado por places).

Failifequal(first, second, msg=none)o : falla si los objetos pasados.

Como parámetros son iguales.

Failunless(expr, msg=none)o : falla a menos que la expresión sea cierta.

Failunlessalmostequal(first, second, places=7, msg=none)o : falla a menos que los objetos pasados como parámetros sean iguales hasta el séptimo decimal (o hasta el número de decimales indicado por places).

Failunlessequal(first, second, msg=none)o : falla a menos que los objetos pasados como parámetros sean iguales.

Failunlessraises(excclass, callábleobj, *args, **kwargs)o : falla a menos que al llamar al objeto callábleobj con los parámetros.

Definidos por *args y **kwargs se lance una excepción de tipo excclass.

Como vemos todos los métodos cuentan con un parámetro opcional msg con un mensaje a mostrar cuando dicha comprobación falle.

Retomemos nuestra función para calcular el cuadrado de un número. Para probar el funcionamiento de la función podríamos hacer, por ejemplo, algo así.

Import unittest.

Def cuadrado (num):
Calcula el cuadrado de un número.

Return num ** 2
Class ejemplopruebas(unittest. Testcase):
Def test(self):
L = [0, 1, 2, 3]
R = [cuadrado (n) for n in l]
Self, assertequal(r, [0, 1, 4, 9])
If __name__ == __main__:
Unittest, main().

preparación del contexto
En ocasiones es necesario preparar el entorno en el que queremos que se ejecuten las pruebas. Por ejemplo, puede ser necesario introducir unos valores por defecto en una base de datos, crear una conexión con una máquina, crear algún archivo, etc. Esto es lo que se conoce en el mundo de xunit como test fixture.

La clase testcase proporciona un par de métodos que podemos sobrescribir para construir y desconstruir el entorno y que se ejecutan antes y después de las pruebas definidas en esa clase. Estos métodos son setup() y teardown().

Class ejemplofixture (unittest. Testcase):
Def setup(self):
Print preparando contexto
Self, lista = [0, 1, 2, 3]
Def test(self):
Print ejecutando prueba
R = [cuadrado (n) for n in self, lista]
Self, assertequal(r, [0, 1, 4, 9])
Def teardown(self):
Print desconstruyendo contexto
Del self, lista.

[3dpoder]

distribuir aplicaciones Python
.Una vez terminemos con el desarrollo de nuestra nueva aplicación es conveniente empaquetarla de forma que sea sencillo para los usuarios instalarla, y para nosotros distribuirla.

En Python existen dos módulos principales para este cometido: distutils, que es parte de la librería estándar y era el método más utilizado hasta hace poco, y setuptools, que extiende la funcionalidad de distutils.

Y es cada vez más popular.

En este capítulo veremos el funcionamiento de ambas herramientas, y terminaremos explicando cómo crear ejecutables.exe para Windows a partir de nuestro programa en Python.
distutils
Todo programa distribuido con distutils contiene un script llamado.

Por convención setup, py, que se encarga de instalar la aplicación llamando a la función setup de distutils, Core. Esta función tiene montones de argumentos, que controlan, entre otras cosas, ¿cómo instalar la aplicación.

Destinados a describir la aplicación tenemos los siguientes argumentos:

• name : el nombre del paquete.
• versión : el número de versión.
• description : una línea describiendo el paquete.
• long_description : descripción completa del paquete.
• author : nombre del autor de la aplicación.
• author_email : correo electrónico del autor.
• maintainer : nombre de la persona encargada de mantener el paquete, si difiere del autor.
• maintainer_email : correo de la persona encargada de mantener el paquete, si difiere del autor.
• url : web de la aplicación.
• download_url : url de la que descargar la aplicación.
• license : licencia de la aplicación.

También tenemos argumentos que controlan los archivos y directorios que deben instalarse, como son packages, py_modules, scripts y ext_modules.

El parámetro scripts, que es una lista de cadenas, indica el nombre del módulo o módulos principales, es decir, los que ejecuta el usuario. Si nuestra aplicación consistiera, por ejemplo, en un solo script ejemplo, py, el código de setup, py podría tener un aspecto similar al siguiente.

From distutils, Core import setup.

Setup(name=aplicación de ejemplo, versión=0.1, description=ejemplo del funcionamiento de distutils, author=Raúl González, author_email=zotropo en Gmail, url=http://mundogek.net/tutorial-Python/, license=GPL, scripts=[ejemplo, py]
).

Si hemos escrito otros módulos para ser utilizados por el script principal, estos se indican mediante el parámetro py_modules. Por ejemplo, supongamos que la aplicación consiste en un script principal ejemplo, py, y un módulo de apoyo apoyo, py.

From distutils, Core import setup.

Setup(name=aplicación de ejemplo, versión=0.1, description=ejemplo del funcionamiento de distutils, author=Raúl González, author_email=zotropo en Gmail, url=http://mundogek.net/tutorial-Python/, license=GPL, scripts=[ejemplo, py], py_modules=[apoyo]
).

Para instalar paquetes Python (directorios que contienen varios módulos y un archivo __init__.py) usaríamos el parámetro packages. Si además del módulo ejemplo, py quisiéramos instalar los paquetes GUI y base de datos, por ejemplo, haríamos algo así.

From distutils, Core import setup.

Setup(name=aplicación de ejemplo, versión=0.1, description=ejemplo del funcionamiento de distutils, author=Raúl González, author_email=zotropo en Gmail, url=http://mundogek.net/tutorial-Python/, license=GPL, scripts=[ejemplo, py], packages=[GUI, base de datos]
).

Ext_modules, por último, sirve para incluir extensiones que utilice el programa, en c, C++, fortran.

Veamos ahora cómo se utilizaría el archivo setup, py una vez creado.

Al ejecutar el comando.

Python setup, py install.

Los módulos y paquetes especificados por py_modules y packages se instalan en el directorio lib de Python. Los programas indicados en scripts, se copian al directorio scripts de Python.

Una vez hemos comprobado que la aplicación se instala correctamente, procedemos a crear archivos mediante los que distribuir la aplicación a los usuarios. Para crear archivos con el código fuente se utiliza la opción sdist de setup, py, que crea por defecto un archivo (*.tar), (*.gz) en Unix y un (*.zip) en Windows.

Python setup, py sdist.

Sin embargo, se puede utilizar -formats para especificar el formato o formatos que queramos generar.


Para crear un archivo (*.tar), bz2, un (*.tar), (*.gz) y un (*.zip,) por ejemplo, se utilizaría la siguiente orden.

Python setup, py sdist -formats=bztar, gztar, zip.

Para generar un archivo de distribución binaria, se usa la opción bdist.

Python setup, py bdist.

Los formatos que soporta bdist son los siguientes:

Para crear un archivo rpm y un instalador de Windows, por ejemplo, escribiríamos.

Python setup, py bdist -formats=wininst, rpm.

También es posible crear otros tipos de archivos de distribución utilizando scripts que extienden distutils, como es el caso de los paquetes deb mediante el script stdeb (http://stdeb. Python-hosting.com/).
setuptools
Setuptols extediende distutils añadiendo una serie de funcionalidades muy interesantes: introduce un nuevo formato de archivo para distribución de aplicaciones Python llamado egg, se encarga de buscar todos los paquetes que deben instalarse y añadir las posibles dependencias, permite instalar paquetes de pypi con un solo comando, etc.

Además, como setuptools se basa en distutils, un script de instalación básico utilizando setuptools es prácticamente igual a su equivalente con distutils. Tan sólo cambiaría la sentencia de importación.

From setuptools import setup.

Setup(name=aplicación de ejemplo, versión=0.1, description=ejemplo del funcionamiento de distutils, author=Raúl González, author_email=zotropo en Gmail, url=http://mundogek.net/tutorial-Python/, license=GPL, scripts=[ejemplo, py]).

El único inconveniente que podríamos encontrar al uso de setuptools es que no está incluido por defecto en Python 2.5, aunque es probable que esto cambie en próximas versiones debido a su gran uso. Pero los desarrolladores de setuptools han pensado en todo, e incluso esto no debería suponer ningún problema, ya que, con un mínimo esfuerzo por nuestra parte podemos hacer que setuptools se descargue e instalé automáticamente en la máquina del usuario si este no se encuentra ya en el sistema. Basta distribuir con nuestro paquete un pequeño módulo extra ez_setup, py que viene incluido por defecto con setuptools (http://peak, telecommunity.com/dist/ez_setup, py) y llamar a la función use_setuptools del módulo al inicio de setup, py.

From ez_setup import use_setuptools.

Use_setuptools()
From setuptools import setup.

Setup(name=aplicación de ejemplo, versión=0.1, description=ejemplo del funcionamiento de distutils, author=Raúl González, author_email=zotropo en Gmail, url=http://mundogek.net/tutorial-Python/, license=GPL, scripts=[ejemplo, py]).

Veamos ahora con más detenimiento algunos de los cambios y novedades que introduce setuptools.
integración con pypi
Al estilo de cpan en perl setuptools permite instalar de forma fácil y sencilla los paquetes pertenecientes a pypi, el índice de paquetes Python (http://pypi. Python.org/pypi), así como subir nuestros propios paquetes.

Pypi cuenta en el momento de escribir estas líneas con 4782 paquetes, por lo que poder instalar los paquetes de este repositorio con un simple comando supone una ayuda muy a tener en cuenta.

Instalar un paquete de pypi es tan sencillo como pasar al comando easy_install el nombre del paquete a instalar.

Easy_install docutils.

Searching for docutils.

Reading http://pypi. Python.org/simple/docutils/
Reading http://docutils.sourceforge.net/
Best match: docutils 0.5
Downloading http://prdownloads.sourceforge.net/d..., gz? Download
Processing docutils-0.5.tar, gz.

Running docutils-0.5/setup, py -que bdist_egg -dist-dir /tmp/easy_install-wuayuz/docutils-0.5/egg-dist-tmp-kwkv.

Optparse module already present, ignoring extras/optparse, py.

Textwrap module already present, ignoring extras/textwrap, py, zip_safe flag not set, analyzing archive contents, docutils.writers, newlatex2e.__init__: module referencias __file__
Docutils.writers, pep_html.__init__: module referencias __file__
Docutils.writers.html4css1.__init__: module referencias __file__
Docutils.writers, s5_html.__init__: module referencias __file__
Docutils, parsers, rst, directives, Misc: module referencias __file__
Adding docutils 0.5 todo easy-install, pth file.

Installing rst2pseudoxml, py script todo /usr/bin.

Installing rst2html, py script todo /usr/bin.

Installing rst2latex.py script todo /usr/bin.

Installing rst2s5.py script todo /usr/bin.

Installing rst2newlatex.py script todo /usr/bin.

Installing rstpep2html, py script todo /usr/bin.

Installing rst2xml, py script todo /usr/bin.

Installed /usr/lib/python2.5/site-packages/docutils-0.5-py2.5.egg.

Processing dependencies for docutils.

Finished processing dependencies for docutils.

Poder subir nuestros paquetes a pypi requiere de un proceso un poco más laborioso. Primero registramos los detalles de nuestra aplicación en pypi mediante la opción register del script setup, py, el cual nos preguntara por nuestro nombre de usuario, contraseña y correo electrónico si no tenemos cuenta en pypi, o nombre de usuario y contraseña si nos registramos anteriormente:
Python setup, py register.

Running register.

Running egg_info.

Creating aplicación_de_ejemplo, egg-info.
Writing aplicación_de_ejemplo, egg-info/pkg-info.
Writing top-level names todo aplicación_de_ejemplo, egg-info/top_level, txt.
Writing dependency_links todo aplicación_de_ejemplo, egg-info/dependency_links, txt.
Writing manifest file aplicación_de_ejemplo, egg-info/sources, txt
Reading manifest file aplicación_de_ejemplo, egg-info/sources, txt
Writing manifest file aplicación_de_ejemplo, egg-info/sources, txt
We ned todo know who you are, so por favor choose either:
1, use your existing login, 2, register as a new user, 3, have the server generate a new password for you (and email it todo you), or.
4, quit.

Your selection [default 1]: 1
Username: zotropo.

Password:
Server response (200): ok.

I can estore your pypi login so future submissions Will be faster, (the login Will be estored in /home/zotropo/.pypirc)
Save your login (y/n)? Y.

Para crear y subir una distribución con el código fuente de nuestra aplicación se utiliza la opción sdist upload.

Python setup, py sdist upload.

También podríamos crear y subir un egg (un formato de archivo para distribuir aplicaciones Python que veremos en la próxima sección) utilizando la opción bdist_egg upload.

Python setup, py bdist_egg upload.

O combinar los tres pasos en un solo comando.

Python setup, py register sdist bdist_egg upload.

Una vez subido el paquete cualquier persona podría instalarlo en su sistema utilizando easy_install, de la misma forma que cualquier otro paquete de pypi.

Easy_install mi-paquete.

eggs
Los eggs (huevo en inglés) son archivos de extensión.egg mediante los que distribuir aplicaciones en Python. Serían algo, así como el equivalente a los archivos.jar del mundo java. Son multiplataforma, permiten manejar dependencias, y permiten instalar distintas versiones del mismo paquete.

La forma más sencilla de instalar aplicaciones distribuidas como archivos egg es mediante el comando easy_install, el cual comentamos brevemente en el punto anterior al hablar sobre su uso para instalar paquetes de pypi. Para instalar un archivo egg no tenemos más que pasarle el nombre del archivo al comando easy_install.

Easy_install mi-aplicación, egg.

O bien podemos pasarle la url de la que descargar el egg.

Easy_install http://mundogek.net/mi-aplicación, egg.

Para construir nuestros propios eggs podemos utilizar el comando bdist_egg de setup, py, de forma similar a la manera en que construíamos paquetes rpm o instaladores para Windows con distutils.

Python setup, py bdist_egg.

otros cambios destacables
Uno de los cambios más interesantes es la incorporación de un nuevo.

Argumento para la función setup llamado install_requires, que consiste en una cadena o lista de cadenas que indica los paquetes de los que depende la aplicación. Si nuestra aplicación necesitara tener instalado el paquete apoyo para poder ejecutarse, por ejemplo, escribiríamos lo siguiente.

Install_requires = [apoyo].

Y de esta forma, easy_install se encargaría de buscar e instalar el paquete si fuera necesario, bien en pypi, o en cualquier otro repositorio indicado por el parámetro dependency_links.

Además, podemos especificar que se necesita una versión concreta del paquete requerido, que sea mayor o menor que una cierta versión, o que no se trate de una versión determinada utilizando operadores relacionales (==.=, <, <=, >, >=).

Install_requires = [apoyo >= 1.0 < 2.0].

También existen argumentos similares para declarar paquetes que deben instalarse para poder ejecutar el script de instalación (setup_requires), para poder ejecutar las posibles pruebas incluidas con el paquete (tests_require) y para conseguir funcionalidades adicionales (extras_require, que consiste en este caso en un diccionario).

Setuptols incluye también atajos útiles, como la función find_packages() que nos evita tener que listar todos y cada uno de los paquetes que utiliza nuestro script en el parámetro packages, ¿cómo era el caso de distutils.

From ez_setup import use_setuptools.

Use_setuptools()
From setuptools import setup, find_packages.

Setup(name=aplicación de ejemplo, versión=0.1, description=ejemplo del funcionamiento de distutils, author=Raúl González, author_email=zotropo en Gmail, url=http://mundogek.net/tutorial-Python/, license=GPL, scripts=[ejemplo, py], packages = find_packages()
).

crear ejecutables.exe
Tanto en Mac os como en la mayor parte de las distribuciones Linux el intérprete de Python está instalado por defecto, por lo que los usuarios de estos sistemas no tienen mayor complicación a la hora de instalar y ejecutar aplicaciones escritas en Python.

En el caso de Windows, esto no es así, por lo que sería interesante que los usuarios de este sistema operativo no tuvieran que instalar el intérprete de Python. También sería interesante que nuestro programa consistiera en un archivo.exe en lugar de uno o varios archivos.py, para simplificar las cosas.

Todo esto lo podemos lograr gracias a py2exe, una extensión para distutils que, como su nombre indica, permite crear ejecutables para Windows a partir de código Python, y que permite ejecutar estas aplicaciones sin necesidad de tener instalado el intérprete de Python en el sistema.

Py2exe funciona examinando nuestro código fuente en busca de los módulos y paquetes que utilizamos, compilando y construyendo un nuevo archivo que incluye estos archivos y un pequeño intérprete de Python integrado.

Para probar el funcionamiento de py2exe creemos un pequeño programa ejemplo, py.

Print soy un (*.exe).

Y el archivo setup, py correspondiente. Los cambios que tenemos que realizar a setup, py son sencillos: importar py2exe, y utilizar los argumentos console y Windows para indicar el nombre del script o scripts que queramos convertir en ejecutables de consola o ejecutables de interfaz gráfica, respectivamente.

From distutils, Core import setup.

Import py2exe.

Setup(name=aplicación de ejemplo, versión=0.1, description=ejemplo del funcionamiento de distutils, author=Raúl González, author_email=zotropo en Gmail, url=http://mundogek.net/tutorial-Python/, license=GPL, scripts=[ejemplo, py], console=[ejemplo, py]
).

Para crear el ejecutable, utilizamos una nueva opción de línea de comandos para setup, py disponible tras importar el módulo y llamada, ¿cómo no, py2exe.

Python setup, py py2exe.

Con esto py2exe generara un directorio build, con las librerías compiladas, y un directorio Dist, con los archivos que conforman nuestra aplicación.

Entre los archivos que podemos encontrar en Dist tendremos uno o varios ejecutables con el mismo nombre que los scripts indicados en console y Windows, un archivo Python*.dll, que es el intérprete de Python, y un archivo library, (*.zip), que contiene varios archivos pyc que son los módulos que utiliza la aplicación compilados.

Si queremos reducir el número de archivos a distribuir, podemos utilizar la opción -bundle de py2exe para añadir a library, (*.zip) las (*.dll) y los pyd (-bundle 2) o las dll, los pyd y el intérprete (-bundle 1).

Python setup, py py2exe -bundle 1.

O bien podemos añadir un nuevo argumento options a la función setup que indique el valor a utilizar (opción bundle_files), de forma que no tengamos que añadir el flag -bundle cada vez que usemos el comando py2exe.

From distutils, Core import setup.

Import py2exe.

Setup(name=aplicación de ejemplo, versión=0.1, description=ejemplo del funcionamiento de distutils, author=Raúl González, author_email=zotropo en Gmail, url=http://mundogek.net/tutorial-Python/, license=GPL, scripts=[ejemplo, py], console=[ejemplo, py], options={py2exe: {bundle_files: 1}}
).

Por último, podemos incluso prescindir de library, (*.zip) e incrustarlo en el ejecutable utilizando el argumento zipfile=none.

From distutils, Core import setup.

Import py2exe.

Setup(name=aplicación de ejemplo, versión=0.1, description=ejemplo del funcionamiento de distutils, author=Raúl González, author_email=zotropo en Gmail, url=http://mundogek.net/tutorial-Python/, license=GPL, scripts=[ejemplo, py], console=[ejemplo, py], options={py2exe: {bundle_files: 1}}, zipfile=none.
).

Fin de este estupendo manual, como dije al principio del primer mensaje, tenga en cuenta que este manual está disponible en formato pdf, adjunto al primer mensaje, donde podrá leer con más comodidad e incluso imprimirlo, te recomiendo pruebes la descarga directa del mismo, desde la página del autor: http://mundogek.net/tutorial-Python/ en caso de funcionar este enlace, puedes hacer la descarga directa desde el primer mensaje.
3dpoder.

-- IMÁGENES ADJUNTAS --