[Python] doctest con funzioni che aprono files

Daniele Varrazzo piro a develer.com
Mer 26 Nov 2008 19:56:45 CET



On Wed, 26 Nov 2008 19:11:24 +0100, "Giovanni Marco Dall'Olio"
<dalloliogm a gmail.com> wrote:

>> Tu sei sicuro che una docstring nella quale hai buttato dentro tutto il
>> codice boilerplate per fargli aprire un file temporaneo abbia ancora una
>> qualche utilità come docstring?
> 
> Per alcune cose che devo fare, si.
> Sto contribuendo al progetto biopython, una collezione di moduli per
> la bioinformatica in python.

Lo conosco, ho studiato bioinformatica per la tesi di laurea e ci ho
lavorato a Siena per 2-3 annetti :)


> Visto che questi moduli devono essere utilizzati da terze parti,
> aggiungere un esempio del file di input nel doctest e' una cosa
> utilissima.
> In questo modo, un utente che si ritrovi a riutilizzare le mie
> librerie, potra' avere una idea chiara del formato per il quale un
> modulo e' stato scritto (pensa soprattutto a quando devi parsare un
> particolare formato di testo).

Ok, quindi nella docstring metti anche il formato del file di testo da
parsare.

> Certamente, anche se devo ammettere di non aver usato molto unittest.

Questo mi spiega ancora meglio come mai usi così estensivamente doctest e
non unittest :)

Secondo me hai sbagliato in partenza a far sì che le tue funzioni di
parsing accettino un filename in input. Se le tue funzioni accettassero un
file object invece avresti i seguenti vantaggi (i primi che mi vengono in
mente):

 - potresti parsare stdin (e quindi mettere una serie di script in pipe). 
   Per esempio parsare un file preso da internet con "curl URL | python
parser.py"

 - potresti usare la doctest con lo StringIO :)

Lo svantaggio nell'aprire un file normale è minimo: anzichè fare
parse(filename) farai parse(open(filename)). 

È anche facile fare una funzione che, in caso di stringa, la "apra"
assumendo un filename ("if isinstance(file, basestring): file =
open(file)"), ma poi vorrai anche distinguere una url per aprirla con
urllib, ma a volte la stringa contiene i dati... la cosa migliore per fare
un parser generico credo sia accettare solo un file object in input e
lasciare che sia il cliente della funzione ad accontentarla (mi sembra una
corretta divisione delle responsibilità).

-- 
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com


Maggiori informazioni sulla lista Python