Re: [Python] Eseguire del codice in una stringa (gestione aggiornamenti?)
> Date: Thu, 18 Feb 2010 21:46:54 +0100
> From: mich...@nectarine.it
[...]
> Ora, il RE ha un compito ben preciso: scaricare [e supponiamo, per
> ora, che questo venga fatto in modo sicuro e senza modifiche] il
> codice sorgente dell'applicazione, e non ci preoccupiamo per ora di
> come lo scarica.
> Quello che voglio realizzare in questo modo e` un'applicazione che si
> autoaggiorna ad ogni avvio, scaricando il codice sorgente ed
> eseguendolo.
[...]
> Prima domanda: e` possibile tutto cio` ?
> Seconda domanda: quali sono i metodi che devo guardarmi? eval() e
> compile() possono fare al caso mio?
>
> Vi ringrazio.
>Michele
[...]
Mi permetto di rispondere alla tua prima domanda: Personalmente, ho già usato
questa tecnica.
Supponiamo, come dici, di avere il modulo RE e un modulo Applicazione
accessibile da parte di RE in esecuzione.
In questo caso, quando RE deve aggiornare Applicazione può fare così:
appl = 'Applicazione'
del sys.modules[appl]
exec( '''import {0}'''.format(appl) )
N.B. exec solleva un eccezione se l'import va male: ti stai esponendo
al rischio di importare del codice non più funzionante o peggio...
Conviene evitare di re-importare in un sol colpo tutta
l'Applicazione. Se Applicazione è suddivisa in più package, puoi
importare all'occorrenza solo la parte effettivamente modificato dal
precedente import.
Ciao.
Matteo.
_
Scatta, ritocca e condividi le tue foto online. Gratis per te
http://www.windowslive.it/foto.aspx___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Eseguire del codice in una stringa (gestione aggiornamenti?)
On 02/18/2010 09:46 PM, mich...@nectarine.it wrote: > Ora, il RE ha un compito ben preciso: scaricare [e supponiamo, per > ora, che questo venga fatto in modo sicuro e senza modifiche] il > codice sorgente dell'applicazione, e non ci preoccupiamo per ora di > come lo scarica. > Quello che voglio realizzare in questo modo e` un'applicazione che si > autoaggiorna ad ogni avvio, scaricando il codice sorgente ed > eseguendolo. > E il sistema "scarico l'applicazione, la scrivo su filesystem e la lancio" non funzione perche'..?? -- This e-mail (and any attachment(s)) is strictly confidential and for use only by intended recipient(s). Any use, distribution, reproduction or disclosure by any other person is strictly prohibited. The content of this e-mail does not constitute a commitment by the Company except where provided for in a written agreement between this e-mail addressee and the Company. If you are not an intended recipient(s), please notify the sender promptly and destroy this message and its attachments without reading or saving it in any manner. Any non authorized use of the content of this message constitutes a violation of the obligation to abstain from learning of the correspondence among other subjects, except for more serious offence, and exposes the person responsible to the relevant consequences. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Come fareste voi?
Ciao a tutti,
vorrei chiedervi se conoscete un modo per snellire un aspetto tedioso
nello [mio modo di] sviluppare in python.
Spesso, soprattutto nelle fasi iniziali di stesura del codice, uso un
editor di testo (emacs o altro)
e tengo aperto un interprete python. Con l'editor definisco la mia
brava classina "testclass" in un file (p. es: test.py )
e un paio di metodini che poi provo al volo per vedere se sono
corretti. Per esempio:
s...@lapdp:~/py$ python
Python 2.5.5 (r255:77872, Feb 1 2010, 19:53:42)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import test
>>> p=test.testclass('testfile.conf')
>>> p.setRFK('teststring')
>>>
In questo caso tutto ok. Il codice ha funzionato.
Quel che accade normalmente, pero', e' che ci sia un bug nel metodino
nuovo appena scritto e l'interprete sollevi la
sua brava eccezione dettagliando il problema.
Leggo, correggo e salvo, poi riprovo.
Per riprovare pero', non basta un semplice:
del test
import test
eccetera.
Facendo questo mi ritorna la vecchia incarnazione della classe, cioe'
python ignora bellamente
il fatto che il file sia cambiato e l'aver dato
del test
non ha veramente cancellato dalla memoria dell'interprete la sua esistenza.
Devo invece uscire da python, rientrare, ripetere i passi daccapo.
La mia domanda quindi e' se posso forzare python a rileggere il file
senza dover uscire e rientrare da python?
In altre parole: esiste un modo piu' "brutale" di del ?
Grazie per i vostri benevoli pareri...
Stefano
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
2010/2/19 Stefano Dal Pra > Per riprovare pero', non basta un semplice: > > del test > import test > eccetera. > > Facendo questo mi ritorna la vecchia incarnazione della classe, cioe' > python ignora bellamente > il fatto che il file sia cambiato e l'aver dato > del test > non ha veramente cancellato dalla memoria dell'interprete la sua esistenza. > reload(test.py) ? p.s. non c'entra niente, peró ti consiglio di usare ipython come interprete interattivo al posto di python. > Devo invece uscire da python, rientrare, ripetere i passi daccapo. > > La mia domanda quindi e' se posso forzare python a rileggere il file > senza dover uscire e rientrare da python? > In altre parole: esiste un modo piu' "brutale" di del ? > > Grazie per i vostri benevoli pareri... > > Stefano > ___ > Python mailing list > Python@lists.python.it > http://lists.python.it/mailman/listinfo/python > -- Giovanni Dall'Olio, phd student Department of Biologia Evolutiva at CEXS-UPF (Barcelona, Spain) My blog on bioinformatics: http://bioinfoblog.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
2010/2/19 Giovanni Marco Dall'Olio > > > 2010/2/19 Stefano Dal Pra > > Per riprovare pero', non basta un semplice: >> >> del test >> import test >> eccetera. >> >> Facendo questo mi ritorna la vecchia incarnazione della classe, cioe' >> python ignora bellamente >> il fatto che il file sia cambiato e l'aver dato >> del test >> non ha veramente cancellato dalla memoria dell'interprete la sua >> esistenza. >> > > > reload(test.py) ? > scusami, chiaramente é: >>> reload(test) o >>> reload(nomedelmodulo) se ho capito bene la tua domanda. -- Giovanni Dall'Olio, phd student Department of Biologia Evolutiva at CEXS-UPF (Barcelona, Spain) My blog on bioinformatics: http://bioinfoblog.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
import test
...
...
...
reload(test)
Simone Federici
---
Software Architect
2010/2/19 Stefano Dal Pra
> Ciao a tutti,
> vorrei chiedervi se conoscete un modo per snellire un aspetto tedioso
> nello [mio modo di] sviluppare in python.
>
> Spesso, soprattutto nelle fasi iniziali di stesura del codice, uso un
> editor di testo (emacs o altro)
> e tengo aperto un interprete python. Con l'editor definisco la mia
> brava classina "testclass" in un file (p. es: test.py )
> e un paio di metodini che poi provo al volo per vedere se sono
> corretti. Per esempio:
>
>
> s...@lapdp:~/py$ python
> Python 2.5.5 (r255:77872, Feb 1 2010, 19:53:42)
> [GCC 4.4.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import test
> >>> p=test.testclass('testfile.conf')
> >>> p.setRFK('teststring')
> >>>
>
> In questo caso tutto ok. Il codice ha funzionato.
>
> Quel che accade normalmente, pero', e' che ci sia un bug nel metodino
> nuovo appena scritto e l'interprete sollevi la
> sua brava eccezione dettagliando il problema.
> Leggo, correggo e salvo, poi riprovo.
>
> Per riprovare pero', non basta un semplice:
>
> del test
> import test
> eccetera.
>
> Facendo questo mi ritorna la vecchia incarnazione della classe, cioe'
> python ignora bellamente
> il fatto che il file sia cambiato e l'aver dato
> del test
> non ha veramente cancellato dalla memoria dell'interprete la sua esistenza.
>
> Devo invece uscire da python, rientrare, ripetere i passi daccapo.
>
> La mia domanda quindi e' se posso forzare python a rileggere il file
> senza dover uscire e rientrare da python?
> In altre parole: esiste un modo piu' "brutale" di del ?
>
> Grazie per i vostri benevoli pareri...
>
> Stefano
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
Grazie mille!
Oso rilanciare, visto che mi avete risolto il problema in 2 min.
Se uno facesse invece:
from test import x,y,z
si potrebbe fare lo stesso?
( il reload mi va benissimo, per carita', ma se sapete qualcosa anche
per questo caso...)
Ciao
Stefano
2010/2/19 Simone Federici :
> import test
> ...
> ...
> ...
> reload(test)
>
>
>
>
> Simone Federici
> ---
> Software Architect
>
>
>
> 2010/2/19 Stefano Dal Pra
>>
>> Ciao a tutti,
>> vorrei chiedervi se conoscete un modo per snellire un aspetto tedioso
>> nello [mio modo di] sviluppare in python.
>>
>> Spesso, soprattutto nelle fasi iniziali di stesura del codice, uso un
>> editor di testo (emacs o altro)
>> e tengo aperto un interprete python. Con l'editor definisco la mia
>> brava classina "testclass" in un file (p. es: test.py )
>> e un paio di metodini che poi provo al volo per vedere se sono
>> corretti. Per esempio:
>>
>>
>> s...@lapdp:~/py$ python
>> Python 2.5.5 (r255:77872, Feb 1 2010, 19:53:42)
>> [GCC 4.4.3] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import test
>> >>> p=test.testclass('testfile.conf')
>> >>> p.setRFK('teststring')
>> >>>
>>
>> In questo caso tutto ok. Il codice ha funzionato.
>>
>> Quel che accade normalmente, pero', e' che ci sia un bug nel metodino
>> nuovo appena scritto e l'interprete sollevi la
>> sua brava eccezione dettagliando il problema.
>> Leggo, correggo e salvo, poi riprovo.
>>
>> Per riprovare pero', non basta un semplice:
>>
>> del test
>> import test
>> eccetera.
>>
>> Facendo questo mi ritorna la vecchia incarnazione della classe, cioe'
>> python ignora bellamente
>> il fatto che il file sia cambiato e l'aver dato
>> del test
>> non ha veramente cancellato dalla memoria dell'interprete la sua
>> esistenza.
>>
>> Devo invece uscire da python, rientrare, ripetere i passi daccapo.
>>
>> La mia domanda quindi e' se posso forzare python a rileggere il file
>> senza dover uscire e rientrare da python?
>> In altre parole: esiste un modo piu' "brutale" di del ?
>>
>> Grazie per i vostri benevoli pareri...
>>
>> Stefano
>> ___
>> Python mailing list
>> Python@lists.python.it
>> http://lists.python.it/mailman/listinfo/python
>
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
Stefano Dal Pra spiffera, alle Friday 19 February 2010 circa: > La mia domanda quindi e' se posso forzare python a rileggere il file > senza dover uscire e rientrare da python? > In altre parole: esiste un modo piu' "brutale" di del ? reload(test) bye -- -gaspa- --- https://launchpad.net/~gaspa - - HomePage: http://gaspa.yattaweb.it -- -Il lunedi'dell'arrampicatore: www.lunedi.org - ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
Il 19/02/2010 11:59, Stefano Dal Pra ha scritto:
> Grazie mille!
>
> Oso rilanciare, visto che mi avete risolto il problema in 2 min.
>
> Se uno facesse invece:
>
> from test import x,y,z
>
> si potrebbe fare lo stesso?
>
> ( il reload mi va benissimo, per carita', ma se sapete qualcosa anche
> per questo caso...)
>
> Ciao
> Stefano
>
> 2010/2/19 Simone Federici :
>> import test
>> ...
>> ...
>> ...
>> reload(test)
>>
>>
>>
>>
>> Simone Federici
>> ---
>> Software Architect
>>
>>
>>
>> 2010/2/19 Stefano Dal Pra
>>>
>>> Ciao a tutti,
>>> vorrei chiedervi se conoscete un modo per snellire un aspetto tedioso
>>> nello [mio modo di] sviluppare in python.
>>>
>>> Spesso, soprattutto nelle fasi iniziali di stesura del codice, uso un
>>> editor di testo (emacs o altro)
>>> e tengo aperto un interprete python. Con l'editor definisco la mia
>>> brava classina "testclass" in un file (p. es: test.py )
>>> e un paio di metodini che poi provo al volo per vedere se sono
>>> corretti. Per esempio:
>>>
>>>
>>> s...@lapdp:~/py$ python
>>> Python 2.5.5 (r255:77872, Feb 1 2010, 19:53:42)
>>> [GCC 4.4.3] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>> import test
>> p=test.testclass('testfile.conf')
>> p.setRFK('teststring')
>>
>>>
>>> In questo caso tutto ok. Il codice ha funzionato.
>>>
>>> Quel che accade normalmente, pero', e' che ci sia un bug nel metodino
>>> nuovo appena scritto e l'interprete sollevi la
>>> sua brava eccezione dettagliando il problema.
>>> Leggo, correggo e salvo, poi riprovo.
>>>
>>> Per riprovare pero', non basta un semplice:
>>>
>>> del test
>>> import test
>>> eccetera.
>>>
>>> Facendo questo mi ritorna la vecchia incarnazione della classe, cioe'
>>> python ignora bellamente
>>> il fatto che il file sia cambiato e l'aver dato
>>> del test
>>> non ha veramente cancellato dalla memoria dell'interprete la sua
>>> esistenza.
>>>
>>> Devo invece uscire da python, rientrare, ripetere i passi daccapo.
>>>
>>> La mia domanda quindi e' se posso forzare python a rileggere il file
>>> senza dover uscire e rientrare da python?
>>> In altre parole: esiste un modo piu' "brutale" di del ?
>>>
>>> Grazie per i vostri benevoli pareri...
>>>
>>> Stefano
>>> ___
>>> Python mailing list
>>> Python@lists.python.it
>>> http://lists.python.it/mailman/listinfo/python
>>
>>
>> ___
>> Python mailing list
>> Python@lists.python.it
>> http://lists.python.it/mailman/listinfo/python
>>
>>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
Non funzionerebbe ugualmente perché ogni modulo può essere importato una
sola volta; un secondo import dello stesso modulo verrebbe semplicemente
ignorato.
Comunque, per python 3.x è necessario però importare la funzione reload
dal modulo imp:
from imp import reload
Mi permetto di precisarlo perché mi è già capitato di sbatterci la
testa. Magari a qualcuno sarà utile...
Leonardo M. Millefiori
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
from test import x,y,z ... ... ... import test reload(test) from test import x,y,z Simone Federici --- Software Architect 2010/2/19 Andrea Gasparini > Stefano Dal Pra spiffera, alle Friday 19 February 2010 circa: > > La mia domanda quindi e' se posso forzare python a rileggere il file > > senza dover uscire e rientrare da python? > > In altre parole: esiste un modo piu' "brutale" di del ? > > reload(test) > > bye > -- > -gaspa- > --- > https://launchpad.net/~gaspa - > - HomePage: http://gaspa.yattaweb.it -- > -Il lunedi'dell'arrampicatore: www.lunedi.org - > ___ > Python mailing list > Python@lists.python.it > http://lists.python.it/mailman/listinfo/python > ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
On Fri, 19 Feb 2010 11:59:05 +0100, Stefano Dal Pra wrote: > Grazie mille! > > Oso rilanciare, visto che mi avete risolto il problema in 2 min. > > Se uno facesse invece: > > from test import x,y,z > > si potrebbe fare lo stesso? > > ( il reload mi va benissimo, per carita', ma se sapete qualcosa anche > per questo caso...) In linea di principio, reload(x.y.z) funziona. In pratica, meno, perché se altri modi (es. x.y o x.y.w) hanno importato x.y.z, il loro puntatore non cambia. O se cambi un modulo usato da x.y.z devi reloadare prima il modulo, poi x.y.z. Io usavo trucchi di "deep reload" per ovviare alla cosa. Ora non trovo più facilmente riferimenti alla cosa su google: dovresti indagare meglio, io non ho tempo ora scusa. Non so se invece qualcuno ha già qualcosa da farti leggere a portata di mano. deep reload è un palliativo (piallativo?...) Il modo buono di fare le cose è di scrivere il tuo test in una unit test e far girare questo ogniqualvolta cambi qualcosa: è stato così che ho smesso di usare deep reload e largamente dimenticato i problemi che comunque lasciava aperti. Ti sembra di perdere tempo... in realtà dopo mezz'ora che fai così ti accorgi che di tempo ne risparmi parecchio. Usa unittest della stdlib e/o nosetest (http://somethingaboutorange.com/mrl/projects/nose/0.11.1/) e vedi che la shell per i test la userai sempre meno. Ciao! -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
Stefano Dal Pra wrote: > Ciao a tutti, > vorrei chiedervi se conoscete un modo per snellire un aspetto tedioso > nello [mio modo di] sviluppare in python. > ... Ti suggerisco un approccio TDD (Test Driven Development): http://en.wikipedia.org/wiki/Test-driven_development in python di solito si usa la libreria unittest. -- Riccardo Lemmi ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] wrpping di librerie c/c++
Salve ragazzi ... vorrei imparare a "wrappare" delle librerie di una applicazione, ho trovato questo pdf che indica vari metodi : http://teckla.idyll.org/~t/transfer/public/day3.pdf .. sapete consigliarmi .. conoscete qualche guida (magari in italiano) ? purtroppo non sono un programmatore esperto, conosco un pò python ma ho scarse conoscenze di c/c++ ... ciò significa che da parte mia ci dovrà essere un bello sforzo :-/. vi ringrazio per un qualsiasi consiglio. Ciao, Massimo.___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
On Feb 19, 2010, at 12:50 PM, Riccardo Lemmi wrote: > Ti suggerisco un approccio TDD (Test Driven Development): > > http://en.wikipedia.org/wiki/Test-driven_development Assolutamente quoto. > in python di solito si usa la libreria unittest. O nose... io ultimamente lo apprezzo molto.___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
Grazie a tutti; Il TDD e' interessante. Ho installato nose e ho provato, ma non ho cavato risultati utili nei 30 secondi che gli ho dedicato. Tornero' alla carica con un po' di pazienza. D'altra parte mi son fatto l'idea che tenere un interprete aperto per testare porzioncine di codice (anche come palestra di sintassi, se vogliamo) sia gia' una rudimentale forma di tdd e considerato che mi sono appassionato a python anche grazie a queste possibilita', credo proprio che lo provero'. Grazie, ciao Stefano 2010/2/19 Enrico Franchi : > > On Feb 19, 2010, at 12:50 PM, Riccardo Lemmi wrote: > > Ti suggerisco un approccio TDD (Test Driven Development): > > http://en.wikipedia.org/wiki/Test-driven_development > > Assolutamente quoto. > > in python di solito si usa la libreria unittest. > > O nose... io ultimamente lo apprezzo molto. > ___ > Python mailing list > Python@lists.python.it > http://lists.python.it/mailman/listinfo/python > > ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
On Feb 19, 2010, at 3:10 PM, Stefano Dal Pra wrote: > Il TDD e' interessante. Molto. > Ho installato nose e ho provato, ma non ho cavato risultati utili > nei 30 secondi che gli ho dedicato. Tornero' alla carica con un > po' di pazienza. Ce ne vogliono circa 45... 30 sono troppo pochi. :) > D'altra parte mi son fatto l'idea che tenere un interprete aperto > per testare porzioncine di codice (anche come palestra di sintassi, se > vogliamo) > sia gia' una rudimentale forma di tdd > e considerato che mi sono appassionato a python anche grazie > a queste possibilita', credo proprio che lo provero'. Ni... da un certo punto di vista la testabilita' di pezzi di codice immediatamente e' una cosa molto comoda e davvero cruciale nel modo di lavorare in Python. Io la uso spesso per provare nuove liberie, intuizioni etc. In un certo senso viene dai tradizionali REPL, dove il modello stateless rende la cosa ancora piu' comoda. Il TDD e' molto piu' di questo: e' proprio una metodologia di sviluppo, non una pratica facility che si ha come side-effect delle features del linguaggio. Ultimamente posso dirti che in Python lavoro con WingIDE. Gia'... io sono un "uomo dei true editors", ma e' troppo comodo. :) Di fatto ho sempre la finestrina con un python dentro, e gli tiro dentro il codice che scrivo nei files (con semplici "run current file/region in interpreter") *E* mi interfaccio ai vari nose e combriccola. Poi possiamo discutere tanto di ste cose... sono interessanti e si impara sempre qualcosa di nuovo. Tipicamente ognuno ha "trucchi" e metodi di lavoro pezzi dei quali sono integrabili anche in metodi di lavoro diversi. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
On Fri, Feb 19, 2010 at 03:10:29PM +0100, Stefano Dal Pra wrote: > Grazie a tutti; > > Il TDD e' interessante. > Ho installato nose e ho provato, ma non ho cavato risultati utili > nei 30 secondi che gli ho dedicato. Tornero' alla carica con un > po' di pazienza. > > D'altra parte mi son fatto l'idea che tenere un interprete aperto > per testare porzioncine di codice (anche come palestra di sintassi, se > vogliamo) > sia gia' una rudimentale forma di tdd > e considerato che mi sono appassionato a python anche grazie > a queste possibilita', credo proprio che lo provero'. Non voglio distoglierti dalla raccomandazione che ti han dato in vari di imparare a sviluppare codice basandosi sui test, è una pratica fruttuosa e rapidamente si ripaga dandoti una bella serenità per ogni futura rimanipolazione del tuo codice. Credo però anche che questo non sia contrapposto all'uso di una shell (certo ipython è molto più comoda di python) con cui provare frammenti di codice, ed io ne faccio un uso frequente. Visto che hai detto che usi emacs perché non sfrutti C-c C-c che manda in esecuzione il codice e ti apre un buffer con il risultato? Mentre i test li uso per testare pezzi del codice che sto scrivendo, di come voglio che si comporti, l'uso cui hai accenato serve anche solo come studio di come si comporta il linguaggio, un passo che può essere strumentale a quello della scrittura del tuo codice. sandro *:-) -- Sandro Dentella *:-) http://sqlkit.argolinux.orgSQLkit home page - PyGTK/python/sqlalchemy ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
Il giorno 19/feb/2010, alle ore 15.27, Enrico Franchi ha scritto: > Ultimamente posso dirti che in Python lavoro con WingIDE. Gia'... io sono un > "uomo dei true editors", ma e' troppo comodo. :) WingIDE è davvero comodo. Se solo fosse Cocoa sarebbe la perfezione;) G ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
> O nose... io ultimamente lo apprezzo molto. In questa lista si è sponsorizzato a più riprese nose, qualcuno può dire come si confronta con py.test? A me piaciono anche i doctest quando penso ai test come documentazione di API ma sia nose che py.test possono eseguire i test in formato doctest ma danno un sommario molto povero ovvero cosiderano un file.txt con dentro i test come un singolo test, quando il modulo doctest li considera sigolarmente. Inoltre io non sono riuscito ad usare in modo utile l'opzione per cui note/py.test aprono la shell di debug quando capita un errore, cosa che invece funziona bene sia con nose che con py.test con test di tipo unittest. sandro *:-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
2010/2/19 Alessandro Dentella > > O nose... io ultimamente lo apprezzo molto. > > > In questa lista si è sponsorizzato a più riprese nose, qualcuno può dire > come si confronta con py.test? > Questo thread sta diventando interessante, peró un poco fuori topic, giá che il titolo originale non era granché... Secondo me se uno ha una domanda, é meglio farla in un nuovo thread e con un nuovo titolo, per fare meno confusione. -- Giovanni Dall'Olio, phd student Department of Biologia Evolutiva at CEXS-UPF (Barcelona, Spain) My blog on bioinformatics: http://bioinfoblog.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] tabelle htm a csv
Ciao a tutti... sono piuttosto nuovo a python urllib, minidom ecc.. credo di aver capito che gli strumenti di cui sopra mi possano servire per trasformare automaticamente in csv le tabelle che trovo qui: http://www.cfcalabria.it/index.php?option=com_wrapper&view=wrapper&Itemid=41 seguendo i vari link... ad esempio questa: http://www.cfcalabria.it/DatiVari/midmar/banca_dati.php?p=visualizza_dati_mensili&codice=2874&par=NGGP la parte di iterazione su tutte le tabelle potrei poi risolverla a parte... quello che mi manca è proprio capire come posso prnedere il dato (urllib.urlopen??) e poi "sezionarlo" per ottenere una matrice da esportare in csv.. conto nel vostro buon cuore :-) ciao Ivan -- Ti prego di cercare di non inviarmi files .dwg, .doc, .xls, .ppt. Preferisco formati liberi. Please try to avoid to send me .dwg, .doc, .xls, .ppt files. I prefer free formats. http://it.wikipedia.org/wiki/Formato_aperto http://en.wikipedia.org/wiki/Open_format Ivan Marchesini Perugia (Italy) Socio fondatore GFOSS "Geospatial Free and Open Source Software" http://www.gfoss.it e-mail: marches...@unipg.it ivan.marches...@gmail.com fax (home): +39(0)5782830887 jabber: geoiva...@jabber.org skype: geoivan73 signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] test [was: Re: Come fareste voi?]
On Fri, 19 Feb 2010 19:36:02 +0100, Alessandro Dentella wrote: >> O nose... io ultimamente lo apprezzo molto. > > > In questa lista si è sponsorizzato a più riprese nose, qualcuno può dire > come si confronta con py.test? Sono uguali: se ne usi uno difficilmente rimpiangi l'altro (secondo me). > A me piaciono anche i doctest quando penso ai test come documentazione di > API ma sia nose che py.test possono eseguire i test in formato doctest ma > danno un sommario molto povero ovvero cosiderano un file.txt con dentro i > test come un singolo test, quando il modulo doctest li considera > sigolarmente. > > Inoltre io non sono riuscito ad usare in modo utile l'opzione per cui > note/py.test aprono la shell di debug quando capita un errore, cosa che > invece funziona bene sia con nose che con py.test con test di tipo > unittest. Perché, e qui lo dichiaro pubblicamente, i doctest sono la tecnologia di test più abusata e meno adatta che sia venuto in mente a chiunque abbia visto un prompt fatto così: >>> I doctest sono un brillante modo di testare... la documentazione!!! da quando sono diventati un modo di testare il programma? Purtroppo da abbastanza presto, e sono uno strumento oscenamente scomodo per farlo, nel senso che costringono a contorsioni da kamasutra per eliminare la variabilità che c'è nell'output dei comandi [1] o per mettere insieme una test suite con setup e teardown. In tutto questo le docstring perdono il significato originale: essere documentazione concisa. [1] http://docs.python.org/library/doctest.html#option-flags-and-directives Ed Loper, autore di Epydoc (credo anche uno degli autori di doctest), ha usato solo doctest per documentare Epydoc stesso [2]. Ma tu guarda che si è dovuto inventare [3] per far girare una test suite un po' più complessa?!?! Ne è valsa la pena? A me non sembra. [2] http://epydoc.svn.sourceforge.net/viewvc/epydoc/trunk/epydoc/src/epydoc/test/ [3] http://epydoc.svn.sourceforge.net/viewvc/epydoc/trunk/epydoc/src/epydoc/test/util.py?revision=1502&view=markup Quindi per me SE uno scrive delle docstring e SE nelle docstring capita che ci sia un esempio autocontenuto (e non "fetch restituisce un record: >>> Record.fetch()..." e poi serve un database e come configurare il DSN di test...) allora tu fai girare i doctest e verifichi che la docstring sia consistente con quello che dichiara. Che poi siano anche test aggiuntivi per la test suite completa del programma, tanto meglio. Ma che le docstring sostituiscano una unit test apposita, secondo me, è un giochino carino, divertente, ma durato troppo. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] tabelle htm a csv
2010/2/19 ivan marchesini
> Ciao a tutti...
> sono piuttosto nuovo a python urllib, minidom ecc..
>
> credo di aver capito che gli strumenti di cui sopra mi possano servire
> per trasformare automaticamente in csv le tabelle che trovo qui:
>
> http://www.cfcalabria.it/index.php?option=com_wrapper&view=wrapper&Itemid=41
> seguendo i vari link...
> ad esempio questa:
>
> http://www.cfcalabria.it/DatiVari/midmar/banca_dati.php?p=visualizza_dati_mensili&codice=2874&par=NGGP
>
> la parte di iterazione su tutte le tabelle potrei poi risolverla a parte...
> quello che mi manca è proprio capire come posso prnedere il dato
> (urllib.urlopen??) e poi "sezionarlo" per ottenere una matrice da
> esportare in csv..
>
html = urllib.urlopen("http://www.cfcalabria.eccetera";).read()
A questo punto io userei Beatiful Soup per tirare fuori la tabella dalla
stringa html
Ciao.
Marco.
--
http://python.thinkcode.tv - Videocorso di Python
http://stacktrace.it - Aperiodico di resistenza informatica
http://beri.it - Blog di una testina di vitello
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
On Feb 19, 2010, at 7:06 PM, Giovanni Porcari wrote: > WingIDE è davvero comodo. Se solo fosse Cocoa sarebbe la perfezione;) Ah, ma lo sai che sono stracostretto a quotarti. GTK e' veramente una iattura su OS X. Ma anche cosi' *IMHO* e' piu' comodo[0] delle alternative. -- [0] nel senso che dopo avere speso quello che ho speso per comprarlo evito di perdere tempo per aggiungerne tutte le funzionalita' ad Emacs[1], con un risparmio in termini di tempo e di fun completamente superiore alla cifra spesa. [1] e' possibile sostituire liberamente vim ad Emacs nella frase precedente. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] tabelle htm a csv
2010/2/19 Marco Beri A questo punto io userei Beatiful Soup per tirare fuori la tabella dalla > stringa html > "Beautiful Soup" Sorry. -- http://python.thinkcode.tv - Videocorso di Python http://stacktrace.it - Aperiodico di resistenza informatica http://beri.it - Blog di una testina di vitello ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] test [was: Re: Come fareste voi?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniele Varrazzo ha scritto: > [...] >> Inoltre io non sono riuscito ad usare in modo utile l'opzione per cui >> note/py.test aprono la shell di debug quando capita un errore, cosa che >> invece funziona bene sia con nose che con py.test con test di tipo >> unittest. > > Perché, e qui lo dichiaro pubblicamente, i doctest sono la tecnologia di > test più abusata e meno adatta che sia venuto in mente a chiunque abbia > visto un prompt fatto così: >>> > Concordo su tutto. Cominci ad usare una cosa perchè è comoda, e finisci con l'abusarne, insistendo anche quando perdi la comodità e l'espressività. Ciao Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt+7h0ACgkQscQJ24LbaUS2OwCePgc1wlTLk8OrfI+3Xzty+Bfp ZBcAn3UBMMs7kkfRMpLJvFO5Bhic0D9l =/KF2 -END PGP SIGNATURE- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] test [was: Re: Come fareste voi?]
> Perché, e qui lo dichiaro pubblicamente, i doctest sono la tecnologia di > test più abusata e meno adatta che sia venuto in mente a chiunque abbia > visto un prompt fatto così: >>> > > I doctest sono un brillante modo di testare... la documentazione!!! da > quando sono diventati un modo di testare il programma? Purtroppo da > abbastanza presto, e sono uno strumento oscenamente scomodo per farlo, nel > senso che costringono a contorsioni da kamasutra per eliminare la > variabilità che c'è nell'output dei comandi [1] o per mettere insieme una > test suite con setup e teardown. In tutto questo le docstring perdono il > significato originale: essere documentazione concisa. > > [1] > http://docs.python.org/library/doctest.html#option-flags-and-directives > > Ed Loper, autore di Epydoc (credo anche uno degli autori di doctest), ha > usato solo doctest per documentare Epydoc stesso [2]. Ma tu guarda che si è > dovuto inventare [3] per far girare una test suite un po' più complessa?!?! > Ne è valsa la pena? A me non sembra. > > [2] > http://epydoc.svn.sourceforge.net/viewvc/epydoc/trunk/epydoc/src/epydoc/test/ A me pare che questo esempio sia un esempio dove la doctest abbia un senso e sia anche più chiaro di quanto potrebbero essere degli unittest o test di nose/py.test, che è probabilmntee simile a quello che dicevi prima: test della documentazione. > [3] > http://epydoc.svn.sourceforge.net/viewvc/epydoc/trunk/epydoc/src/epydoc/test/util.py?revision=1502&view=markup Questo molto meno, ma: 1. probabilmente anche in uno unittest avrebbero dovuto esserci delle test/helper function fatte per rendere i test più leggibili... 2. proprio perché ce ne è più di uno mi pare che sia corretto scegliere il migliore per ogni singola situazione. E` corretto chiedere che si evitino contorsionismi strani, ma spesso la leggibilità di test fatti con doctest è decisamente elevata. Sono anche convinto che la flessibilità delle unittest (o simili) sia molto maggiore in varie circostanze per cui non ci rinuncerei affatto. sandro *:-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Come fareste voi?
On Feb 19, 2010, at 7:36 PM, Alessandro Dentella wrote: > In questa lista si è sponsorizzato a più riprese nose, qualcuno può dire > come si confronta con py.test? Quoto quello che dice Daniele. Sono grosso modo equivalenti. Io ho iniziato con nose perche' in quel periodo mi sembrava leggermente meglio. Possibile anche che il mio giudizio fosse sbagliato, ma ormai... Tra l'altro anche leggendo il libro di Tarek si ha la stessa impressione. Quello che posso dirti e' che (senza essere esperto di py.test): 1. di fico ha il "disabilitamento booleano" di test 2. di fico ha funzioni di testing distribuito[0] 3. e' parte di un framework piu' grande (giudica tu se e' un bene o un male) 4. non ha un sistema di plugin come nose per essere integrato nel setup Ciascuna fra la 1,2,4 potrebbe essere cambiata (aggiunta anche a nose o aggiunta anche a py.test). Tarek consiglia nose "a meno che non ti serva qualcosa che py.test ha e nose no". Ognuno poi prova come preferisce. - [0] che a me non servono *e* credo "in genere" non servano > A me piaciono anche i doctest quando penso ai test come documentazione di > API ma sia nose che py.test possono eseguire i test in formato doctest ma > danno un sommario molto povero ovvero cosiderano un file.txt con dentro i > test come un singolo test, quando il modulo doctest li considera > sigolarmente. Ancora una volta sono d'accordo con Daniele. I doctest vengono facilissimamente abusati. Alcune volte sono veramente comodi: per esempio per il codice molto algoritmico li uso (eventualmente insieme a codice piu' mirato) per mostrare il funzionamento di metodi e funzioni... quindi *molto* come documentazione. Ma, a volte, anche come test vero e proprio. Nel caso "generale" faticherei ad usarli. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] tabelle htm a csv
Marco Beri wrote: > A questo punto io userei Beatiful Soup per tirare fuori la tabella > dalla stringa html Io no. Anche di recente abbiamo (hanno) avuto problemi in ditta con Beautiful Soup, e siamo passati a usare lxml.html . Anche il parser di html5lib non è male. Inoltre Beautiful Soup è praticamente non più mantenuto, vedi archivi di it.comp.lang.python per dettagli. -- Nicola Larosa - http://www.tekNico.net/ We appear to be the only screen entering mass production designed for reading that offers color, video, longer battery life and works as-is with existing software stacks (from OS to viewers) and in any lighting condition including the pitch black and outside in direct sunlight and integrates easily with touchscreens. - Mary Lou Jepsen, October 2009 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] test [was: Re: Come fareste voi?]
On Fri, 19 Feb 2010 22:51:12 +0100, Alessandro Dentella wrote: > 1. probabilmente anche in uno unittest avrebbero dovuto esserci delle > test/helper function fatte per rendere i test più leggibili... Il fatto è che in una unit test le funzioni helper sono codice messo a fianco al codice, con funzioni che chiamano altre funzioni... normalissimo python, no? Una doctest è un'imbragatura sadomaso che costringe ad un'unica funzione di test, ovvero "assert str(o) == s" con s costante. Qualunque test lo devi ridurre a questo, tutti i metodi che ti aspetti in un framework di test suite ricco (es. assertAlmostEqual...) te lo scordi e devi sempre starti ad inventare un helper() per cui str(helper(o)) == s. Se anche devi mettere funzioni helper in una test suite, hanno la possibilità di lavorare su tipi di dati più ricchi, sfruttando tutto quello che offre il linguaggio, anziché rimpiazzare stringhe su stringhe fino a ridurre il risultato una costante da confrontare per eguaglianza col prototipo (ah, a meno di IGNORE_EXCEPTION_DETAIL e NORMALIZE_WHITESPACE... altre funzioni che trasformano testo in testo) > 2. proprio perché ce ne è più di uno mi pare che sia corretto scegliere > il > migliore per ogni singola situazione. > > E` corretto chiedere che si evitino contorsionismi strani, ma spesso > la > leggibilità di test fatti con doctest è decisamente elevata. Già parlare di metodologie è soggettivo, parlare di leggibilità forse lo è anche di più... In ogni caso io definisco una docstring leggibile quando è documentazione leggibile, non quando è un test leggibile. E visto che i test *puoi* metterli altrove ma le docstring no, devono stare nel modulo, e visto che 500 righe di test ci stanno bene su un metodo di 10 righe, ma 500 righe di test in mezzo a metodi di 10 righe (e dico proprio *in mezzo*, tra un metodo e l'altro)... io le docstring non le ammiro. > Sono anche convinto che la flessibilità delle unittest (o simili) sia > molto > maggiore in varie circostanze per cui non ci rinuncerei affatto. Non ho intenzione di farti cambiare idea: visto che lo strumento è stato citato, queste sono le mie considerazioni e i motivi per cui io non le uso se non per testare documentazione. Secondo me la documentazione deve essere esplicativa mentre i test devono essere esaustivi: visto i due obiettivi spesso finiscono con l'essere in contraddizione preferisco tenerli fisicamente separati e usare lo strumento migliore per l'obiettivo. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
