On Wed, 26 Nov 2008 19:11:24 +0100, "Giovanni Marco Dall'Olio" <[EMAIL PROTECTED]> 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 _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python