[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