Re: [Python] test mail, plz ignore

[Patrick Arminio]

❤️

On Fri, 14 May 2021 at 12:10, Carlo Miron  wrote:

> 
>
> --
>  THE -WARE LICENSE (Revision ㊷):
>  wrote this . As long as you retain this notice you
> can
> do whatever you want with this stuff. If we meet some day, and you
> think this stuff is worth it, you can buy me a  in return. — Carlo
> ___
> Python mailing list
> Python@lists.python.it
> https://lists.python.it/mailman/listinfo/python
>


-- 
Patrick Arminio
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python

[Python] test mail, plz ignore

[Carlo Miron]



-- 
 THE -WARE LICENSE (Revision ㊷):
 wrote this . As long as you retain this notice you can
do whatever you want with this stuff. If we meet some day, and you
think this stuff is worth it, you can buy me a  in return. — Carlo
___
Python mailing list
Python@lists.python.it
https://lists.python.it/mailman/listinfo/python

Re: [Python] test mail

[Simone Federici]

Carlo Miron:

> pls ignore me.
>

I wish I could ignore you like you ignore me.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] test mail

[Carlo Miron]

pls ignore me.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test on Python

[Roberto Polli]

Il 02/mag/2016 12:15, "Marco Badan"  ha scritto:
> Test-Driven Development with Python
> Obey the Testing Goat:
+1

Pax R
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test on Python

[Stefano Bossi]

Io consiglio di iniziare con il libro di Kent Beck che il TDD l'ha
inventato :)

http://www.amazon.it/Test-Driven-Development-Kent-Beck/dp/0321146530



2016-05-02 12:15 GMT+02:00 Marco Badan :

> Il 01 mag 2016 9:27 PM, "Fundor333"  ha scritto:
> >
> > Oltre al manuale ufficiale di python avete qualche altra lettura
> (libri/manuali/tutorial/repository) da consigliare per approffondire
> l'argomento?
>
> Ciao,
>
> Ti consiglio la mia ultima lettura sul TDD:
>
> Test-Driven Development with Python
>
> Obey the Testing Goat: Using Django, Selenium, and JavaScript
>
> http://www.obeythetestinggoat.com/
>
> Sì può pure leggere gratuitamente online
>
> Marco
>
> ___
> 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] Test on Python

[Marco Badan]

Il 01 mag 2016 9:27 PM, "Fundor333"  ha scritto:
>
> Oltre al manuale ufficiale di python avete qualche altra lettura
(libri/manuali/tutorial/repository) da consigliare per approffondire
l'argomento?

Ciao,

Ti consiglio la mia ultima lettura sul TDD:

Test-Driven Development with Python

Obey the Testing Goat: Using Django, Selenium, and JavaScript

http://www.obeythetestinggoat.com/

Sì può pure leggere gratuitamente online

Marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test on Python

[greenkey loman]

Ciao Fundor!

On Sun, May 1, 2016 at 9:27 PM Fundor333  wrote:

> Oltre al manuale ufficiale di python avete qualche altra lettura
> (libri/manuali/tutorial/repository) da consigliare per approffondire
> l'argomento?
>

Non so consigliarti letture, ma se riesci a venire a Milano tra poco faremo
un workshop sul TDD:
http://www.meetup.com/it-IT/Python-Milano/events/230710731/

Ciao,
Lorenzo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Test on Python

[Fundor333]

Grazie a Pycon ho iniziato a sviluppare in python in modo più serio di 
prima  e volevo avere dei tutorial per imparare a usare correttamente il 
pacchetto test per creare test per i programmi che sviluppo.


Oltre al manuale ufficiale di python avete qualche altra lettura 
(libri/manuali/tutorial/repository) da consigliare per approffondire 
l'argomento?


--
Fundor333

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] test

[Carlo Miron]

Il 02/apr/2016 18:30, "Giovanni Porcari"  ha
scritto:

> > Il giorno 02 apr 2016, alle ore 14:39, Gollum1 <
gollum1.smeag...@gmail.com> ha scritto:
> >
> > Il 02 aprile 2016 14:02:19 CEST, Carlo Miron  ha
scritto:
> >> 2016-04-02 13:16 GMT+02:00 Carlos Catucci :
> >>
> >>> On 2 April 2016 at 07:21, Carlo Miron  wrote:
> 
> > Forse qualcuno degli amministratori della lista dovrebbe
> >> semplicemente
> > eliminarlo...
> 
>  fatto, scusate.
> >>>
> >>> Cavolo, sei un killer spietato ;)
> >>
> >> *E* Gollum1 è dietro di me, ora.
> >>
>
>
> Per questo continuavi a sbirciare alle tue spalle ?

:D

no, collo dolorante :(
che brutta cosa invecchiare ;-P

㎝

--
|:**THE BEER-WARE LICENSE** *(Revision 42)*:
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] test

[Giovanni Porcari]

> Il giorno 02 apr 2016, alle ore 14:39, Gollum1  
> ha scritto:
> 
> Il 02 aprile 2016 14:02:19 CEST, Carlo Miron  ha scritto:
>> 2016-04-02 13:16 GMT+02:00 Carlos Catucci :
>> 
>>> On 2 April 2016 at 07:21, Carlo Miron  wrote:
 
> Forse qualcuno degli amministratori della lista dovrebbe
>> semplicemente
> eliminarlo...
 
 fatto, scusate.
>>> 
>>> Cavolo, sei un killer spietato ;)
>> 
>> *E* Gollum1 è dietro di me, ora.
>> 


Per questo continuavi a sbirciare alle tue spalle ?

G



>> ㎝
>> 
>> -- 
>> |:**THE BEER-WARE LICENSE** *(Revision 42)*:
>> |  wrote this mail. As long as you retain
>> | this notice you can do whatever you want with this stuff.
>> | If we meet some day, and you think this stuff is worth it,
>> | you can buy me a beer in return.
>> |--Carlo Miron :
>> ___
>> Python mailing list
>> Python@lists.python.it
>> http://lists.python.it/mailman/listinfo/python
> 
> Bella la maglietta... 
> Sempre dietro io... abbiate timore
> Byez
> -- 
> Gollum1
> 
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli 
> errori di battitura (maledetto correttore ortografico).
> ___
> 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] test

[Gollum1]

Il 02 aprile 2016 14:02:19 CEST, Carlo Miron  ha scritto:
>2016-04-02 13:16 GMT+02:00 Carlos Catucci :
>
>> On 2 April 2016 at 07:21, Carlo Miron  wrote:
>>>
>>> > Forse qualcuno degli amministratori della lista dovrebbe
>semplicemente
>>> > eliminarlo...
>>>
>>> fatto, scusate.
>>
>> Cavolo, sei un killer spietato ;)
>
>*E* Gollum1 è dietro di me, ora.
>
>㎝
>
>-- 
>|:**THE BEER-WARE LICENSE** *(Revision 42)*:
>|  wrote this mail. As long as you retain
>| this notice you can do whatever you want with this stuff.
>| If we meet some day, and you think this stuff is worth it,
>| you can buy me a beer in return.
>|--Carlo Miron :
>___
>Python mailing list
>Python@lists.python.it
>http://lists.python.it/mailman/listinfo/python

Bella la maglietta... 
Sempre dietro io... abbiate timore
Byez
-- 
Gollum1

Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli 
errori di battitura (maledetto correttore ortografico).
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] test

[Carlo Miron]

2016-04-02 13:16 GMT+02:00 Carlos Catucci :

> On 2 April 2016 at 07:21, Carlo Miron  wrote:
>>
>> > Forse qualcuno degli amministratori della lista dovrebbe semplicemente
>> > eliminarlo...
>>
>> fatto, scusate.
>
> Cavolo, sei un killer spietato ;)

*E* Gollum1 è dietro di me, ora.

㎝

-- 
|:**THE BEER-WARE LICENSE** *(Revision 42)*:
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] test

[Carlos Catucci]

On 2 April 2016 at 07:21, Carlo Miron  wrote:

> > Forse qualcuno degli amministratori della lista dovrebbe semplicemente
> eliminarlo...
>
> fatto, scusate.
>
Cavolo, sei un killer spietato ;)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] test

[Carlo Miron]

Il 01/apr/2016 23:17, "Gollum1"  ha scritto:

> Il 01 aprile 2016 18:27:11 CEST, Carlo Miron  ha scritto:
> >2016-04-01 18:26 GMT+02:00  :
> >
> >> L'account leona...@deasistemi.com non è più attivo.
> >
> >grazie della preziosa informazione.
>
> Forse qualcuno degli amministratori della lista dovrebbe semplicemente
eliminarlo...

fatto, scusate.

ciao,

㎝

--
|:**THE BEER-WARE LICENSE** *(Revision 42)*:
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] test

[Gollum1]

Il 01 aprile 2016 18:27:11 CEST, Carlo Miron  ha scritto:
>2016-04-01 18:26 GMT+02:00  :
>
>> L'account leona...@deasistemi.com non è più attivo.
>
>grazie della preziosa informazione.
>___
>Python mailing list
>Python@lists.python.it
>http://lists.python.it/mailman/listinfo/python

Forse qualcuno degli amministratori della lista dovrebbe semplicemente 
eliminarlo...
Byez
-- 
Gollum1

Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli 
errori di battitura (maledetto correttore ortografico).
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] test

[Carlo Miron]

2016-04-01 18:26 GMT+02:00  :

> L'account leona...@deasistemi.com non è più attivo.

grazie della preziosa informazione.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] test

[Carlo Miron]

test
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] test

[leonardo]

L'account leona...@deasistemi.com non è più attivo.


___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-18 16:14 GMT+01:00 Giovanni Porcari :

>
> Se esiste un sistema di test di questo genere e se posso implementarlo ai
> prezzi da
> fame che i clienti sono disposti a pagare vi prego di dirmelo :).


Viaggia nel tempo e procurati degli schiavi. Altri metodi per ora non mi
vengono. Ci sono dei bagali che permettono di automatizzare dei test
funzionali su GUI ma i test dovresti scriverteli e se vuoi coprire tutti i
casi possibili delle cose che l'utente potrebbe fare ...

A proposito di viaggio nel tempo, avrei giusto un annuncio economico da
mettere

A.A.A. Ieri vendero' macchina del tempo perfettamente funzionante. ;)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-18 10:28 GMT+00:00 Carlos Catucci :

> Tutto e' relativo, dipende dal contesto.
>

Yep.


> Io per esempio per garantire di poter lavorare anche se la ruspa dei
> lavori in corso trancia i cavi dell'adsl (ci e' successo realmente a
> Modena) un rapsino con un disco in replica che puo' fungere da macchina di
> backup locale lo propongo. Poi dipende da cosa fa il servizio/applicazione.
> Se devo solo consultare ogni tanto non da problemi, ma se ho tutto li sopra
> ecco che il sistema di backup locale diventa vitale.
>

Breaking news... da qualche mese e' disponibile una nuova cosa chiamata
"cloud computing", che vuole dire che in pratica ti scegli il modello di
ridondanza/availability che vuoi e fine della fiera. Vuoi piu' availably
zones? Puoi. Pensi che tutto sommato devi proteggerti da un evento
catastrofico, che so... in us-east-1? bene... prendi qualcosa anche in
us-east-2. Pensi che tutta l'america possa venire invasa dagli alieni (ci
sono le foto! [0]), prendi qualcosa anche che so... in Australia. I canguri
terranno lontani gli alieni. Etc etc etc. ;)

Poi le ruspe continueranno a tranciare i cavi. Pero' smette di essere un
problema tuo...


---
[0]
http://vignette3.wikia.nocookie.net/aliens/images/b/b2/Alien_Independence_Day.png/revision/latest?cb=20110124141918



-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-18 15:09 GMT+01:00 enrico franchi :

>
> Breaking news... da qualche mese e' disponibile una nuova cosa chiamata
> "cloud computing", che vuole dire che in pratica ti scegli il modello di
> ridondanza/availability che vuoi e fine della fiera. Vuoi piu' availably
> zones? Puoi. Pensi che
>
[...]

> Poi le ruspe continueranno a tranciare i cavi. Pero' smette di essere un
> problema tuo...
>

Enrico se le ruspe tranciano il cavo della connessione dove sono le
postazioni di lavoro (ufficio del cliente) non esiste cloud che mi faccia
andare.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-18 15:59 GMT+01:00 Giovanni Porcari :

> No. Però un bel modem 4G qualcosa di buono fa…


Concordo, se sei coperto da rete 4G. Cosa che per molte (troppe) zone in
questo paese non corrisponde al vero.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-18 10:58 GMT+00:00 Gollum1 :

>
>
> lasciamo perdere va... sono da mesi oramai che chiedo di replicare
> localmente un server di autenticazione, che ora è solo a Roma...
>
> in un paio di occasioni c'é stato un problema sulle linee di
> comunicazione, e ci siamo trovati con la produzione ferma, solo perché
> gli utenti (montatori) non potevano loggarsi sulle macchine di
> montaggio... (una delle due volte, si era spenta tutta la farm in cui
> risiedono i loro server di autenticazione, un disastro).
>
> ma ingegneria non ci sente... stupidi...
>
>
Unipr, l'anno scorso... storia breve, c'era un UPS vecchiotto che stava
schiattando. Dovevano fare lavori elettrici.
Fanno i lavori elettrici. L'UPS era vecchio ed e' schiattato. Doveva essere
ridondato ma non lo era.
Va giu' un po' di roba... nulla di importante, se non, precisamente, il
server di autenticazione. Bene... non ridondato. Meglio. Avevo detto storia
breve? Beh, in pratica *tutto* (email inclusa) ha smesso di funzionare per
10 giorni... fra cui l'iscrizione agli esami.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-15 18:22 GMT+00:00 Carlos Catucci :

> Questione di scala Enrico.


A me verrebbe dire anche questione di business, piuttosto. O se vuoi, del
tipo di business e del modello di deploy che hai.

Per esempio se fai sw "boxed" i rilasci sono costosissimi e vuoi certamente
dell'infrastruttura massiccia di QA. D'altra parte per la maggior parte dei
sw l'utente si aspetta che ci siano dei bachi. Insomma, Word (o chi per
lui) ogni tanto crasha. Lo sappiamo tutti e continuiamo ad usarlo (magari
usiamo il "chi per lui", che a sua volta ogni tanto va giu'). Pero' grosso
modo e' su... il motivo e' che di fatto l'infrastruttura e' interamente in
mano all'utente. Che d'altra parte vuole dire che determinati tipi di
testing diventano molto piu' complicati. Il caso "pessimo" e' quello dei
giochi che magari hanno bachi nei motori grafici che sono triggerati solo
da certe combinazioni di un certo modello di scheda video con una certa
versione dei driver su una certa versione di un certo sistema operativo.

Se c'e' un baco, si considera ok aspettare qualche mese per avere una minor
version che lo aggiusta. Inoltre, se si introduce un baco, basta dare un
buon modo all'utente di usare la vecchia versione e probabilmente gli si da
solo un fastidio marginale. Non solo... certi utenti si aspettano che la
nuova versione abbia bachi e prima di "adottarla" la testano. Pochi, eh...
ma spesso quelli per cui e' veramente critico lo fanno.

Il modello dei servizi web e' opposto. Ci si aspettano rilasci brevi. Ci si
aspetta che il software sia sempre su. I bachi sono una cosa statistica:
ovvero sappiamo che per qualche utente ci saranno dei problemi, ma fintanto
che il singolo utente non ha problemi troppo spesso si puo' tollerare. Poi
ci sono un mucchio di cose che sappiamo che andranno storte... quindi via
di retry. Che so... se faccio una chiamata ad un servizio, puo' andare male
anche solo per questioni di rete o del momento in cui succede. Ma magari il
servizio di per se e' su e non c'e' davvero un "baco" nel codice. Riprovo
tutto e vado. Magari l'utente stesso e' disposto di tanto in tanto a
ricaricare la pagina per aggiustare una situazione.

E anche qui... e' diverso fare un servizio che "vendi" ad un'azienda il cui
business ne dipende. Se "vendo" un servizio di billing per ecommerce e io
sono giu', i miei clienti non possono fatturare. Non saranno tolleranti. Se
fallisco una transazione su 100, non saranno contenti. Se a mia volta il
mio servizio e' un ecommerce, gli stessi problemi sopra descritti possono
volere dire meno vendite e meno soldi. Downtime vuole dire perdite
monetarie quantificabili immediatamente. Non solo... non posso nemmeno
facilmente testare il mio codice in produzione (ovvero, iniziare a
deployare timidamente e sperare che funzioni tutto). Viceversa se sto
facendo un servizio per condividere una bacheca di puttanate con i miei
amici, posso: 1) fallire di tanto in tanto, inoltre, siccome molti fanno
sta roba dal cellulare, potrebbero addirittura pensare che non sono io a
fallire, ma che e' la connessione che e' singhiozzante; 2) testare feature
su pochi clienti alla volta... posso anche convincerli di essere fortunati
a starmi facendo da beta tester a gratis. Un celebre servizio di
microblogging aveva problemi immensi di availability eppure si e' comunque
espanso.

Comunque a prescindere da quale situazione sia, in generale "non so chi
sono i miei clienti". Ovvero sono tanti, continuano ad entrare e,
potenzialmente, ad uscire. Mi possono abbandonare probabilmente con un
costo limitato. La mia reputazione e' una cosa globale, invece: qualche
post su twitter di persone chiave puo' crearmi grossissimi problemi. Tutti
sanno chi sono (o per lo meno, tutti quelli che sono interessati al tipo di
servizio che sto vendendo/proponendo).

Se quello che fai e' invece offrire soluzioni "individuali" per clienti, e'
un mercato ancora diverso. C'e' un rapporto piu' stretto. I tempi in
qualche modo li da il cliente (mentre se faccio servizi web i tempi li da
"il mercato" -- se siamo i secondi a rilasciare questa feature abbiamo
perso la battaglia -- oppure essere quasi interno -- rilascio questa
feature quando e' pronta, o ancora, rilascio tutte le settimane, ma includo
nel rilascio solo quello che e' pronto). E poi dipendera' di volta in volta
come vengono fatti deployment, aggiornamenti, new release; se le macchine
sono mie o del cliente, quanta gestione ho sulle macchine, etc etc etc.


Questo solo per dire che siccome i modelli di business sono davvero
diversi, non e' affatto detto che una strategia completamente accettabile
in una situazione sia completamente suicida in un'altra.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Manlio Perillo]

2016-03-18 16:14 GMT+01:00 Giovanni Porcari :
> [...]
> Altrettanto ovvio (almeno per me) che ogni volta che si fanno delle modifiche 
> o delle
> aggiunte di un certo peso (non quindi il css che colora in rosso una riga se 
> il camion
> non è arrivato) l'utente dispone anche di un'istanza (sempre in claud) di test
> con i dati prelevati ogni notte dal db primario.
>
> Su quella istanza pasticcia un paio di giorni controllando tutto quello
> che è vitale che funzioni in tempo reale (e nei trasporti se tieni fermo
> un camion perchè non puoi stampare la lista di carico la gente si incazza).
>
> Se nel server di test tutto è ok si aggiorna alla stessa release il server di 
> produzione
> con la ragionevole certezza che le procedure critiche sono state testate 
> dagli utenti.
>
> Mi piacerebbe avere un sistema di test che mi segnali che se l'utente dragga
> una riga di trasporto da eseguire nel viaggio previsto per domani
> e se poi cambia idea e la toglie e la mette nel viaggio della settimana
> seguente per un altro trasportatore c'è un baco per cui a video la prima riga
> risulta ancora visibile.
>
> E via dicendo per qualsiasi tipo di evento sia generato da n utenti che 
> lavorano su
> un sistema di questo tipo allocando e deallocando risorse di trasporto.
>
> Se esiste un sistema di test di questo genere e se posso implementarlo ai 
> prezzi da
> fame che i clienti sono disposti a pagare vi prego di dirmelo :).
>

Con Selenium, dovresti essere in grado di controllare se certi
elementi (individuati tramite selettori CSS o query XPATH) sono
visibili, oltre a molto altro ancora.

> [...]

Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-18 18:07 GMT+01:00 enrico franchi :

> No. Ma se la postazione del cliente e' isolata dal mondo, e' un caso molto
> particolare che avendo una specifica applicazione hostata in locale tutto
> funzioni (senza accesso ad internet, a questo punto). Tutto funzioni vuole
> dire "la gente e' in grado di lavorare".
>

Non e' isolata di solito, ma puo' esserlo se hai problemi £temporanei" di
connettivita'. In tal caso la ridondnza locale non ti lascia a piedi e si
sincronizza quando tonra la connessione

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-15 19:09 GMT+01:00 enrico franchi :

> Ottimo. Mi fa piacere che per te funzioni. Vorrei solo che sia chiaro che
> non e' un caso generale che sia facilmente estensibile ad altri business in
> modo automatico. Appena cambi un pochetto le regole del business e' facile
> che non funzioni piu' tanto bene.
>

Questione di scala Enrico. Che poi sia giustissimo e sacrosanto scrivere i
test e' altro discorso. Ma per le cose che fa Giovanni i bug nascosti tra
le pieghe del codice magari sono meno nascosti.
Se hai una applicazione con tre bottoni, ciascuno fa una cosa specifica e
solo una, indipendentemente dall'ordine in cui li stai premendo, i bug sono
facile da beccare con il solo test funzionale di premere tutti e tre e
vedere che ciascuno faccia solo quello che deve fare. Se sempre stesso caso
ma a seconda dell'odine di pressione accade qualcosa di differente (premi
tutti e tre in un dato ordine succede una cosa, li premi in un altro
cuccede un'altar cosa) gia' piu' difficile beccare il bug con il test
funzionale. Se poi i bottonoi sono 30 o 300 ...

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-10 14:21 GMT+00:00 Giovanni Porcari :

>
> Si. Tutto vero.  Tutto sacrosanto. Tutto giusto.
>
> Però come dicevo in un'altra mail è un problema di risorse che puoi avere
> e non avere
> e le compatibilità economiche non sono meno importanti di quelle tecniche.
>

Si, appunto. Per determinati business (che so, se fai servizi web based) il
costo di un baco in produzione sufficientemente grave puo' anche nella
peggiore delle ipotesi farti chiudere baracca. Se i clienti perdono fiducia
nel tuo business, semplicemente non hai piu' clienti (per lo meno, nel
lungo termine). Se il business fa billing sulla base delle transazioni dei
clienti, downtime vuole dire potenzialmente milioni di dollari di mancate
entrate. In ogni caso probabilmente hai delle SLA che devi rispettare, e se
non le rispetti devi sbatterti non poco per scusarti (e generalmente tutto
questo coinvolge ancora una volta mancate entrate)

Certo, se vendi software "boxed" sei in un mondo completamente diverso.
Come e' diverso se vendi soluzioni custom per clienti singoli, e magari ti
va anche bene. Eh, scusa, eravamo giu' per un paio di ore, ma dai, non ti
preoccupare. In altri casi questo e' un pochetto piu' complicato.

Non posso parlare per altri ma solo per me. Lavoro in questo ambito da più
> di 40 anni
> e non ho mai infilato in produzione dei bachi che non fossero 'cosmetici'.
>

Eh... che dire. Bravi. La mia esperienza, sebbene molto piu' breve, e'
tutta diversa.

Diciamo cosi'... l'esperienza (breve finche' vuoi) mi insegna a diffidare
molto di questo tipo di affermazioni.

Nel mio mondo, la parola chiave e' "build to fail". I sistemi falliranno.
Il trucco e' essere sufficientemente ridondanti. E il costo ingegnere di
scrivere un test e' assolutamente *nullo* rispetto al costo di tenere in
piedi la baracca (che a sua volta e' completamente trascurabile rispetto al
costo di fallire davvero).

Che poi questo dipenda da fortuna, capacità, senso di responsabilità o
> attenzione non lo so.
>

La fortuna non perdura in eterno, il senso di responsabilita' non aiuta
(ovvero, l'incoscienza chiaramente rema contro, ma non direi che e' un
problema di "senso di responsabilita'"). Attenzione? Forse. Ma vuole anche
dire che il business ha tempi molto lenti (o se vuoi "umani"). Ma
soprattutto, non e' una garanzia. Perche' sei attento fino alla volta in
cui sei disattento.

Se vai a vedere come gestiscono le cose quelli che *non* possono
permettersi bachi *per nulla* (sarebbe piuttosto sgradevole un 404 con
l'omino dei lavori in corso sul monitor del 747 che sta precipitando con
500 persone a bordo -- sorry, we are working for you: ATC will be online in
a couple of hours, please consult your onboard spiritual advisor for your
last prayers). Beh... vedrai che non ti parlano di "attenzione" e "senso di
responsabilita'". Semmai hanno svariati team di QA che fanno test manuali,
automatici, randomizzati e pagano licenze piuttosto costose per tool che
fanno analisi statica e dimostrano l'assenza di determinati bachi in
determinate parti del codice. E a volte tutto questo si rompe e nonostante
tutto si va Arianne 5.

Ora tutto questo ha un costo immenso. Per lo meno vuole dire un ciclo di
sviluppo cosi' lungo che nel mio mondo saremmo tutti fuori dal business. E
quindi via di compromessi. Oltretutto un moderno sistema software e'
*molto* piu' complicato della maggior parte dei sistemi mission critical di
quel tipo (principalmente perche' il costo di non introdurre una feature
puo' essere molto piu' alto del costo del rischio di un downtime).

Forse il rovescio della medaglia è che se ti convinci che i test comunque
> ti parano il culo
> tendi a lavorare con il medesimo.
>

"True man do not write bugs". No. La gente scrive i test quando lavora
bene. Se non scrive i test, dal mio punto di vista, sta lavorando con il
culo. Ci sono talmente tante buone ragioni per scrivere i test... e quale
ragione per non scriverli? Risparmio tempo? In generale si dimostra che non
e' manco vero che si risparmia tempo sul lungo termine. Poi certo, se uno
se la gioca tutta sul fatto che "va in bancarotta sul debito tecnico" ok...
ma non e' un gran piano nel caso generale.

Un po' come l'acrobata che cammina sul filo senza la rete sotto: o sta
> attento o è un uomo morto.
>

Ecco... ma noi siamo acrobati che lavorano troppe ore al giorno su un filo
invisibile con illuminazione a lume di candela fatta dal pubblico
sottostante. E il filo non e' dritto ma va un po' di qua e un po' di la. E
un orso ubriaco con la faccia di Bruce Campbell ci sta inseguendo con una
motosega al posto della zampa destra.

Io non dico che avere un'ottima copertura dei test sia sbagliato anzi, è
> una cosa meravigliosa.
> Dico solo che io, purtroppo, non me la posso permettere :)
>

E io non conosco il tuo business, per cui non posso e non voglio commentare
oltre. I tuoi clienti sono contenti, restano, e ne continuano ad arrivare
di nuovi? Allora vuole dire che stai facendo 

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Nicola Larosa]

Giovanni Porcari wrote:
> E poi posso sempre passare a Ruby:

Fai pure se credi, ma non passare a Rails.


> http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

Faccio fatica a leggere roba scritta da stronzi:



-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Giovanni Porcari]

> Il giorno 10 mar 2016, alle ore 15:52, Marco Beri  ha 
> scritto:
> 
> 2016-03-10 15:43 GMT+01:00 Giovanni Porcari :
> 
> > Il giorno 10 mar 2016, alle ore 15:36, Nicola Larosa  ha 
> > scritto:
> >
> > Che è più di quanto molti di noi possano vantare, ma non puoi avere
> > culo per sempre. ;-)
> 
> Menagramo :P
> 
> 
>  
> 
> You made my day.

E poi posso sempre passare a Ruby :

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Marco Beri]

2016-03-10 15:43 GMT+01:00 Giovanni Porcari :

>
> > Il giorno 10 mar 2016, alle ore 15:36, Nicola Larosa 
> ha scritto:
> >
> > Che è più di quanto molti di noi possano vantare, ma non puoi avere
> > culo per sempre. ;-)
>
> Menagramo :P
>




You made my day.


-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Giovanni Porcari]

> Il giorno 10 mar 2016, alle ore 15:36, Nicola Larosa  ha 
> scritto:
> 
> Che è più di quanto molti di noi possano vantare, ma non puoi avere
> culo per sempre. ;-)

Menagramo :P

G
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-10 15:36 GMT+01:00 Nicola Larosa :

> Scusa, ma è solo una tua convinzione, secondo me errata. Vedi quanto
> detto da Stefano circa il progettare il codice in funzione dei test.
>

Ecco diciamo che dipende da dove lavori. Sono stato in posti dove il test
veniva considerato uno spreco di tempo a prescindere. C'e' anche da dire
che sono andato via appena possibile.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Nicola Larosa]

Giovanni Porcari wrote:
> Lavoro in questo ambito da più di 40 anni e non ho mai infilato in
> produzione dei bachi che non fossero 'cosmetici'.

Giovanni, scusa ma questo è altamente improbabile (soprattutto se non
avevi test :-) ). Al massimo non ti *risultano* bachi (il che è già un
successo), ma il mondo è pieno di bachi tuoi (come di tutti noi).
Aspettano solo il momento giusto per venir fuori. ;-)

 
> Forse il rovescio della medaglia è che se ti convinci che i test
> comunque ti parano il culo tendi a lavorare con il medesimo.

Questo non ha veramente senso, oltre a non aver riscontro nella realtà.


> Io non dico che avere un'ottima copertura dei test sia sbagliato
> anzi, è una cosa meravigliosa. Dico solo che io, purtroppo, non me
> la posso permettere :)

Scusa, ma è solo una tua convinzione, secondo me errata. Vedi quanto
detto da Stefano circa il progettare il codice in funzione dei test.

 
> Se questo significa lavorare ammerda pazienza. Per ora con questa
> 'ammerda' ho mangiato e non ho mai messo in difficoltà i miei
> clienti :)

Che è più di quanto molti di noi possano vantare, ma non puoi avere
culo per sempre. ;-)

-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Stefano Bossi]

2016-03-10 15:21 GMT+01:00 Giovanni Porcari :

>
> Si. Tutto vero.  Tutto sacrosanto. Tutto giusto.
>
> Però come dicevo in un'altra mail è un problema di risorse che puoi avere
> e non avere
> e le compatibilità economiche non sono meno importanti di quelle tecniche.
> Non posso parlare per altri ma solo per me. Lavoro in questo ambito da più
> di 40 anni
> e non ho mai infilato in produzione dei bachi che non fossero 'cosmetici'.
>
> Che poi questo dipenda da fortuna, capacità, senso di responsabilità o
> attenzione non lo so.
>
> Forse il rovescio della medaglia è che se ti convinci che i test comunque
> ti parano il culo
> tendi a lavorare con il medesimo.
> Un po' come l'acrobata che cammina sul filo senza la rete sotto: o sta
> attento o è un uomo morto.
>
> Io non dico che avere un'ottima copertura dei test sia sbagliato anzi, è
> una cosa meravigliosa.
> Dico solo che io, purtroppo, non me la posso permettere :)
>
> Se questo significa lavorare ammerda pazienza. Per ora con questa
> 'ammerda' ho mangiato e
> non ho mai messo in difficoltà i miei clienti :)
>
> Secondo me l'unico modo per uscirne è lavorare in TDD e a quel punto vuol
dire fare design tramite i test.
Di conseguenza, il tempo dedicato ai test non è in più, ma è quello che
prima dedicavi alla progettazione pura.
Con il TDD riesci a scrivere codice che per forza deve essere testabile e
quindi calano i costi di mantenimento di tutta la suite.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Nicola Larosa]

Enrico Franchi wrote:
> Ma mettere *a priori* l'affermazione "comunque i bachi piu' insidiosi
> non li scopri con i test" e' un po' un blanket statement che si legge
> come: i test non servono davvero troppo, quindi inutile spendere il
> costo di scriverli.

Che è una profezia auto-avverante: se non scrivi test
*sistematicamente*, non saprai mai quanta pena t'avrebbero evitato.


> Fare test come si deve *prima* di andare in produzione tipicamente
> acchiappa un mucchio di bachi.

Intendevi fare test come si deve prima di scrivere il codice. :-)


> Anche perche' se no che faccio... prendo il codice che *credo* fixi
> il baco e lo metto in produzione? E poi scopro che non fixa un
> accidenti? O che magari non ho capito il baco? E che magari il fix
> in realta' oltre fixare un baco introduce un problema? No TY.

Been there, done that, got the T-shirt. Never. Again. Please.


> Aggiungo... secondo me c'e' piu' codice scritto ammerda che codice
> scritto ammodo.

Questo è fuori discussione, il dubbio è su quant'è il codice scritto
come si deve. Dieci per cento? Uno per cento? Uno per mille? Meno?
Quanto meno?

-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Giovanni Porcari]

> Il giorno 10 mar 2016, alle ore 14:58, enrico franchi 
>  ha scritto:
> 
> 
> 
> 2016-03-10 1:34 GMT+00:00 Marco Beri :
> 2016-03-09 23:53 GMT+01:00 Giovanni Porcari :
> Comunque i bachi più insidiosi, purtroppo non li scovi con i test.
> 
> Giovanni, e' una posizione complicata e rischiosa. Cioe', oggettivamente, 
> siamo tutti adulti (chi piu' chi meno) e si puo' ammettere che effettivamente 
> ci sono bachi che fai fatica a scovare con i test. Possiamo anche dire che 
> meno il codice e' testabile e piu' e' facile che suddetti bachi esistano. 
> 
> Pero' mettere "in avanti" questa affermazione porta problemi. E' *diverso* 
> avere il baco, vedere il servizio crollare come un castello di carte, fare 
> root cause analysis, trovare di conseguenza il problema e a quel punto, 
> quando ci si va a chiedere cosa si sarebbe potuto fare per evitarlo (ovvero 
> cosa si fara' perche' non si ripresenti) constatare che si, quel baco era 
> talmente complicato da scovare con i test che di fatto "non si sarebbe potuto 
> fare di meglio" e che l'unica cosa che si puo' fare e' mettere a sto punto 
> dei regression test. A me verrebbe pure da aggiungere che bisognerebbe 
> riflettere sul perche' quel codice contiene bachi insidiosi che non acchiappi 
> con i test (nota, non sto parlando di genro, sono in astratto).
> 
> Ma mettere *a priori* l'affermazione "comunque i bachi piu' insidiosi non li 
> scopri con i test" e' un po' un blanket statement che si legge come: i test 
> non servono davvero troppo, quindi inutile spendere il costo di scriverli.
>   
> Non è che i test ti fanno scoprire i bachi.
> 
> Si, i test ti fanno anche scoprire i bachi. Fare test come si deve *prima* di 
> andare in produzione tipicamente acchiappa un mucchio di bachi. Fare 
> integration testing ne acchiappa altri. Ehi... perfino fare load testing 
> acchiappa "bachi" (ok, tecnicamente non sono bachi, ma sono sempre cose che 
> fanno svegliare la notte e fanno incazzare gli utenti.
>  
> I test ti garantiscono le non regressioni (e già questo li rende 
> irrinunciabili).
> 
> +1
>  
> Poi, quando scovi un baco, la prima cosa da fare è scrivere un test che lo 
> evidenzi. Solo dopo lo correggi (e te ne accorgi quando passa il test che lo 
> evidenziava).
> 
> +1
>  
> Così è più faticoso che fixare subito il baco? Certo. Ma a tendere è più 
> conveniente? Più certo ancora.
> 
> Anche perche' se no che faccio... prendo il codice che *credo* fixi il baco e 
> lo metto in produzione? E poi scopro che non fixa un accidenti? O che magari 
> non ho capito il baco? E che magari il fix in realta' oltre fixare un baco 
> introduce un problema? No TY.
> 
>  
> Dici che c'è del  codice non si può testare?
> Chiedi a Valentino, lui ti direbbe che non esiste codice siffatto :-)
> 
> No no... esiste: si chiama codice scritto ammerda. E' una proprieta' 
> assolutamente cross-platform e cross-linguaggio.
> Aggiungo... secondo me c'e' piu' codice scritto ammerda che codice scritto 
> ammodo. 
>  
> C'è chi sostiene che un bug è in realtà un test non scritto.
> 
> Non troppo lontana dalla realta'. 
> 


Si. Tutto vero.  Tutto sacrosanto. Tutto giusto.

Però come dicevo in un'altra mail è un problema di risorse che puoi avere e non 
avere
e le compatibilità economiche non sono meno importanti di quelle tecniche.
Non posso parlare per altri ma solo per me. Lavoro in questo ambito da più di 
40 anni
e non ho mai infilato in produzione dei bachi che non fossero 'cosmetici'. 

Che poi questo dipenda da fortuna, capacità, senso di responsabilità o 
attenzione non lo so.

Forse il rovescio della medaglia è che se ti convinci che i test comunque ti 
parano il culo
tendi a lavorare con il medesimo.
Un po' come l'acrobata che cammina sul filo senza la rete sotto: o sta attento 
o è un uomo morto.

Io non dico che avere un'ottima copertura dei test sia sbagliato anzi, è una 
cosa meravigliosa.
Dico solo che io, purtroppo, non me la posso permettere :)

Se questo significa lavorare ammerda pazienza. Per ora con questa 'ammerda' ho 
mangiato e 
non ho mai messo in difficoltà i miei clienti :)


Buona giornata :)

G


___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-10 1:34 GMT+00:00 Marco Beri :

> 2016-03-09 23:53 GMT+01:00 Giovanni Porcari 
> :
>
>> Comunque i bachi più insidiosi, purtroppo non li scovi con i test.
>
>
Giovanni, e' una posizione complicata e rischiosa. Cioe', oggettivamente,
siamo tutti adulti (chi piu' chi meno) e si puo' ammettere che
effettivamente ci sono bachi che fai fatica a scovare con i test. Possiamo
anche dire che meno il codice e' testabile e piu' e' facile che suddetti
bachi esistano.

Pero' mettere "in avanti" questa affermazione porta problemi. E' *diverso*
avere il baco, vedere il servizio crollare come un castello di carte, fare
root cause analysis, trovare di conseguenza il problema e a quel punto,
quando ci si va a chiedere cosa si sarebbe potuto fare per evitarlo (ovvero
cosa si fara' perche' non si ripresenti) constatare che si, quel baco era
talmente complicato da scovare con i test che di fatto "non si sarebbe
potuto fare di meglio" e che l'unica cosa che si puo' fare e' mettere a sto
punto dei regression test. A me verrebbe pure da aggiungere che
bisognerebbe riflettere sul perche' quel codice contiene bachi insidiosi
che non acchiappi con i test (nota, non sto parlando di genro, sono in
astratto).

Ma mettere *a priori* l'affermazione "comunque i bachi piu' insidiosi non
li scopri con i test" e' un po' un blanket statement che si legge come: i
test non servono davvero troppo, quindi inutile spendere il costo di
scriverli.


> Non è che i test ti fanno scoprire i bachi.
>

Si, i test ti fanno anche scoprire i bachi. Fare test come si deve *prima*
di andare in produzione tipicamente acchiappa un mucchio di bachi. Fare
integration testing ne acchiappa altri. Ehi... perfino fare load testing
acchiappa "bachi" (ok, tecnicamente non sono bachi, ma sono sempre cose che
fanno svegliare la notte e fanno incazzare gli utenti.


> I test ti garantiscono le non regressioni (e già questo li rende
> irrinunciabili).
>

+1


> Poi, quando scovi un baco, la prima cosa da fare è scrivere un test che lo
> evidenzi. Solo dopo lo correggi (e te ne accorgi quando passa il test che
> lo evidenziava).
>

+1


> Così è più faticoso che fixare subito il baco? Certo. Ma a tendere è più
> conveniente? Più certo ancora.
>

Anche perche' se no che faccio... prendo il codice che *credo* fixi il baco
e lo metto in produzione? E poi scopro che non fixa un accidenti? O che
magari non ho capito il baco? E che magari il fix in realta' oltre fixare
un baco introduce un problema? No TY.



> Dici che c'è del  codice non si può testare?
>
Chiedi a Valentino, lui ti direbbe che non esiste codice siffatto :-)
>

No no... esiste: si chiama codice scritto ammerda. E' una proprieta'
assolutamente cross-platform e cross-linguaggio.
Aggiungo... secondo me c'e' piu' codice scritto ammerda che codice scritto
ammodo.


> C'è chi sostiene che un bug è in realtà un test non scritto.
>

Non troppo lontana dalla realta'.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Giovanni Porcari]

> Il giorno 10 mar 2016, alle ore 11:52, Stefano Bossi  ha 
> scritto:
> 
> Anche se è molto difficile testare le GUI come anche altre forme di IO, 
> questo non vuol dire che non si possa testare tutto il resto.
> Certo, separare tutto ciò che è logica pura dall'IO è una gran fatica, 
> ma almeno sai che quella è solida e questo ha anche il vantaggio di farti 
> scrivere codice più pulito :)

Si infatti: sulla parte python 'core' e adapter_sql abbiamo dei test (anche se 
la copertura non è certo
ottimale). Ma la nostra lotta è quasi sempre sulla GUI e sul timing degli 
eventi.

Ovvero il classico baco che è anche difficile da riprodurre perchè capita 
magari ogni 2 mesi.

Sulla parte interfaccia abbiamo tutta una serie di test ma NON automatici. 
Ovvero se temo
che ci sia un baco ad esempio sulle grid, apro la mia pagina di test delle grid 
e aggiungo un sottocaso per evidenziare il problema o l'anomalia.

Quello che non riesco proprio a fare è capire come posso beccare con test 
automatici
il fatto che resizando la finestra mi compaia una scrollbar nel pannello in 
alto a sx
quando non dovrebbe. Cioè io lo vedo e dico ' cazzo ci vuole un overflow 
hidden'.
Farlo fare ad un test giuro che non saprei da che parte iniziare. Mio limite ;)


G


___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Marco Beri]

2016-03-10 11:52 GMT+01:00 Stefano Bossi :

Anche se è molto difficile testare le GUI come anche altre forme di IO,
> questo non vuol dire che non si possa testare tutto il resto.
> Certo, separare tutto ciò che è logica pura dall'IO è una gran fatica,
> ma almeno sai che quella è solida e questo ha anche il vantaggio di farti
> scrivere codice più pulito :)
>

E, infine, in teoria ti permette di "pluggare" una nuova interfaccia senza
diventare troppo matto..

Ho imparato bene, Stefano? :-)

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Stefano Bossi]

2016-03-09 23:53 GMT+01:00 Giovanni Porcari :

>
> Comunque i bachi più insidiosi, purtroppo non li scovi con i test.
> Almeno in sistemi con delle GUI molto complesse e dove il timing
> degli eventi può essere l'elemento critico.
> A volte per riprodurre un baco bisogna magari cliccare su un bottone
> poi cliccare su un altro e scrollare una griglia avanti e indietro.
>
> Capisci che studiare casi di test per cose simili è quasi impossibile.
>
> Anche se è molto difficile testare le GUI come anche altre forme di IO,
questo non vuol dire che non si possa testare tutto il resto.
Certo, separare tutto ciò che è logica pura dall'IO è una gran fatica,
ma almeno sai che quella è solida e questo ha anche il vantaggio di farti
scrivere codice più pulito :)

stefano
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Riccardo Magliocchetti]

Il 09/03/2016 23:53, Giovanni Porcari ha scritto:

Comunque i bachi più insidiosi, purtroppo non li scovi con i test.
Almeno in sistemi con delle GUI molto complesse e dove il timing
degli eventi può essere l'elemento critico.


Difficile testare la ui ma non impossibile, ad esempio:
http://caolanm.blogspot.it/2015/10/fuzzing-libreoffice-input-events-with.html
http://caolanm.blogspot.it/2015/10/finding-ui-crashes-by-fuzzing-input.html

Oppure fresca di oggi e sul tema property testing:

https://twitter.com/giorgiosironi/status/707862823842533376


--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Nicola Larosa]

> Nicola Larosa wrote:
>> Non sarebbe bello poterli indirizzare sulle porzioni più
>> interessanti dello spazio dei dati, e intanto assicurarsi
>> di esplorare

Qui intendevo "controllare", tra l'altro.


>> certi valori dimostratisi critici? È quello che fa il
>> property-based testing, tra i cui esponenti ci sono
>> QuickCheck (Haskell) del 1999 e ScalaCheck del 2007.

Marco Beri wrote:
> Avevo visto questo talk di Giorgio Sironi all'agile day:
> https://vimeo.com/album/3674400/video/147027434
> 
> Si tratta della stessa cosa, immagino. Giusto?

Sì, vedi a 37:35.

Sulla pagina del talk non trovo le slide, e il pulsante "Talk" in basso
a sinistra non mi funziona né su Firefox, né su Chromium. :-P



-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Giovanni Porcari]

> Il giorno 10 mar 2016, alle ore 02:34, Marco Beri  ha 
> scritto:
> 
> 2016-03-09 23:53 GMT+01:00 Giovanni Porcari :
> Comunque i bachi più insidiosi, purtroppo non li scovi con i test.
> 
> Giovanni,
> credo sia "the other way around".
> 
> Non è che i test ti fanno scoprire i bachi.
> 
> I test ti garantiscono le non regressioni (e già questo li rende 
> irrinunciabili).
> 
> Poi, quando scovi un baco, la prima cosa da fare è scrivere un test che lo 
> evidenzi. Solo dopo lo correggi (e te ne accorgi quando passa il test che lo 
> evidenziava).
> 
> Così è più faticoso che fixare subito il baco? Certo. Ma a tendere è più 
> conveniente? Più certo ancora. Dici che c'è del  codice non si può testare? 
> Chiedi a Valentino, lui ti direbbe che non esiste codice siffatto :-)
> 
> C'è chi sostiene che un bug è in realtà un test non scritto.
> 

Marco non pensare che non sia convinto della necessità di avere dei buoni test
in modo da non essere mai a rischio di regressioni.

Sono certissimo che sia ottima cosa.

Come sono certo, ma davvero certo, che un'ottima documentazione sia la chiave 
di volta
per avere un prodotto condivisibile con altri sviluppatori.

Come sono certo del fatto che dovrei finalmente rompere gli indugi e passare a 
python 3.

Purtroppo, da imprenditori, e io sono un piccolissimo imprenditore, sappiamo 
che ci sono
costi che ti puoi permettere e costi che non ti puoi permettere. Magari vivessi 
in un
altro paese troverei fantomatici finanziatori in grado di assicurarmi le 
risorse per
fare tutto senza dovere ipotecare la casa dove vivo.

Quindi devo fare delle scelte, che, per carità, possono essere alla lunga anche
scelte sbagliate. Ma gli aspetti economici di un progetto sono comunque 
importanti.

In Softwell siamo in tutto 5 sviluppatori e abbiamo scritto tutto Genropy e una 
serie
di applicativi che vanno dalla gestione dei trasporti, alla gestione dei 
contratti 
editoriali, poliambulatori, condomini, gestione di produzione e da ultimo Erpy,
che è un ERP che sta venendo proprio benino.

Tra tutte queste cose l'attività che ci è costata di più è stata di volta in 
volta
la migrazione dei dati da sistemi legacy che andavamo a sostituire. Gestire 
degli interregni
in cui il sistema legacy e quello nuovo coesistono e devono essere tenuti 
sincronizzati
è un piccolo grande incubo.

Poi un altro aspetto che è davvero oneroso è stare dietro alle fantastiche 
trovate
dei nostri governanti. Realizzare in 2 settimane uno 'spesometro' che deve 
riclassificare
 'ad minchiam' dati caricati nell'anno precedente e trasmetterli a chi di dovere
con un formato demenziale è qualcosa che solo chi lo ha fatto può capire quanta 
fatica costi.

Ora purtroppo in questa attività 'concreta' e fatta di costi da tenere 
d'occhio, 
clienti da tenere buoni e opportunità da non perdere, il tempo è quello che è.

La ricerca di bachi è, per fortuna nostra, un qualcosa di poco impegnativo o 
perchè
siamo molto ma molto fortunati o magari perchè la struttura di Genropy, il
modo in cui è stato ideato e scritto, rende i bachi un evento abbastanza 
inconsueto.

Ti racconto l'ultimo baco che abbiamo dovuto scovare. Un certo giorno di circa 
un mese
fa, Google ha improvvisamente aggiornato Chrome introducendo un comportamento
misterioso che rompeva il reload delle nostre pagine.

Ovvio che un baco così significa che tutti i clienti ti chiamano più o meno
contemporaneamente (il fatto che Google ti aggiorni in modo automatico
è una delle cose che detesto di più) e quindi dovevamo trovare il baco
e risolverlo nel giro di minuti.

Dopo circa mezz'ora di imprecazioni e lavoro, il fix è stato fatto e consisteva 
nel
rimpiazzare nel NOSTRO metodo 'reloadPage' l'istruzione:

  window.location.reload();

con:

  window.location.assign(window.location.href);

Questo mi dice 2 cose: la prima è che se nemmeno il sistema di test di Google
gli fa trovare bachi di questo genere prima di aggiornare centinaia di milioni
di browser per il mondo, allora i sistemi di test sono comunque fallaci.

La seconda cosa, assai più importante, è che wrappare in metodi TUOI
il codice secondo la funzione svolta è estremamente importante.

Avrei potuto avere in giro centinaia di chiamate a "window.location.reload();"
magari in n repository e cambiare tutto ovunque sarebbe stato molto dispendioso.

Il fatto di usare il nostro metodo 'pageReload' invece dell'istruzione base
ci ha consentito di fare un unico fix nel framework, pusharlo e fare un pull
in tutti i sistemi dei clienti. 

Quindi in meno di un ora il baco è stato sistemato.

Se avessi dovuto procedere secondo la metodologia canonica, avrei dovuto 
scrivere un
test in javascript che facesse un reload di pagina e verificasse questa 
tipologia
di errore. Forse sarei ancora qui a grattarmi la testa per capire come fare :D

Quindi, riepilogando: 

1) Concordo sul fatto che un buon sistema di test è ottima
   cosa e andrebbe speso tutto il tempo e le 

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Marco Beri]

2016-03-09 23:53 GMT+01:00 Giovanni Porcari :

> Comunque i bachi più insidiosi, purtroppo non li scovi con i test.
>

Giovanni,
credo sia "the other way around".

Non è che i test ti fanno scoprire i bachi.

I test ti garantiscono le non regressioni (e già questo li rende
irrinunciabili).

Poi, quando scovi un baco, la prima cosa da fare è scrivere un test che lo
evidenzi. Solo dopo lo correggi (e te ne accorgi quando passa il test che
lo evidenziava).

Così è più faticoso che fixare subito il baco? Certo. Ma a tendere è più
conveniente? Più certo ancora. Dici che c'è del  codice non si può testare?
Chiedi a Valentino, lui ti direbbe che non esiste codice siffatto :-)

C'è chi sostiene che un bug è in realtà un test non scritto.

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Marco Beri]

2016-03-09 17:19 GMT+01:00 Nicola Larosa :

> Non sarebbe bello poterli indirizzare sulle porzioni più interessanti
> dello spazio dei dati, e intanto assicurarsi di esplorare certi valori
> dimostratisi critici? È quello che fa il property-based testing, tra i
> cui esponenti ci sono QuickCheck (Haskell) del 1999 e ScalaCheck del
> 2007.
>

Avevo visto questo talk di Giorgio Sironi all'agile day:
https://vimeo.com/album/3674400/video/147027434

Si tratta della stessa cosa, immagino. Giusto?

C'è un gran bello strumento anche per Python: Hypothesis. Il suo
> funzionamento è schematizzato in questa slide:
>
> <
> https://speakerdeck.com/michelslm/property-based-testing-in-python-with-hypothesis?slide=11
> >
>
> e l'ottima documentazione contiene un bel pezzo di advocacy:
>
> 
>
> Adesso non avete più scuse: andate e testate!
>

:-))

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Giovanni Porcari]

> Il giorno 09 mar 2016, alle ore 23:40, Giovanni Porcari 
>  ha scritto:
> 
> 
>> Il giorno 09 mar 2016, alle ore 17:19, Nicola Larosa  ha 
>> scritto:
>> 
>> (I'm looking at you, Genropy. ;-) )
> 
> 
> ehm… :D
> 
> G

O per parafrasare Microsoft: 'Che serve testare se ci sono gli utenti che 
pagano per farlo ? '


Comunque i bachi più insidiosi, purtroppo non li scovi con i test.
Almeno in sistemi con delle GUI molto complesse e dove il timing 
degli eventi può essere l'elemento critico.
A volte per riprodurre un baco bisogna magari cliccare su un bottone
poi cliccare su un altro e scrollare una griglia avanti e indietro.

Capisci che studiare casi di test per cose simili è quasi impossibile.

In ogni caso bel prodotto :)

Ciao

G


___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Giovanni Porcari]

> Il giorno 09 mar 2016, alle ore 17:19, Nicola Larosa  ha 
> scritto:
> 
> (I'm looking at you, Genropy. ;-) )


ehm… :D

G
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Federico Fissore]

Potresti dare un'occhiata al mutation testing.

In breve: il codice sotto test viene modificato in N modi, es
if a == b
diventa
if a != b

Se il tuo test si spacca, hai una buona coverage, se il "mutante 
sopravvive", il codice è mal testato


Però non ho esperienza con python, non saprei dirti se c'è una lib e 
qual è la migliore


ciao

fede

Nicola Larosa ha scritto il 09/03/2016 alle 17:19:

Do I have your multilingual attention now? Good. ;-)

Sappiamo tutti che, se da un lato il codice *testato* non garantisce il
corretto funzionamento, dall'altro il codice *non testato* garantisce il
malfunzionamento al 99.99%.

Purtroppo scrivere unit test con un coverage decente è costoso (con
"decente" > 95%): bisogna scrivere molti test, e vanno tenuti
aggiornati mentre il codice evolve.

Ma dato che i test automatizzano l'esecuzione del codice, non sarebbe
bello automatizzare anche la generazione dei test?

È quello che fanno gli strumenti di fuzzy testing: voi scrivete un test
che invoca un pezzo di codice, e loro lo invocano a ripetizione
esplorando casualmente lo spazio dei dati in ingresso.

Sono strumenti efficaci nel trovare bug inaspettati, ed hanno un costo
di utilizzo basso; hanno però il difetto di "sparare nel mucchio",
rischiando di spendere molto tempo su dati poco rilevanti, e al
contempo mancare valori critici.

Non sarebbe bello poterli indirizzare sulle porzioni più interessanti
dello spazio dei dati, e intanto assicurarsi di esplorare certi valori
dimostratisi critici? È quello che fa il property-based testing, tra i
cui esponenti ci sono QuickCheck (Haskell) del 1999 e ScalaCheck del
2007.

C'è un gran bello strumento anche per Python: Hypothesis. Il suo
funzionamento è schematizzato in questa slide:



e l'ottima documentazione contiene un bel pezzo di advocacy:



Adesso non avete più scuse: andate e testate!


(I'm looking at you, Genropy. ;-) )



___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Nicola Larosa]

Do I have your multilingual attention now? Good. ;-)

Sappiamo tutti che, se da un lato il codice *testato* non garantisce il
corretto funzionamento, dall'altro il codice *non testato* garantisce il
malfunzionamento al 99.99%.

Purtroppo scrivere unit test con un coverage decente è costoso (con
"decente" > 95%): bisogna scrivere molti test, e vanno tenuti
aggiornati mentre il codice evolve.

Ma dato che i test automatizzano l'esecuzione del codice, non sarebbe
bello automatizzare anche la generazione dei test?

È quello che fanno gli strumenti di fuzzy testing: voi scrivete un test
che invoca un pezzo di codice, e loro lo invocano a ripetizione
esplorando casualmente lo spazio dei dati in ingresso.

Sono strumenti efficaci nel trovare bug inaspettati, ed hanno un costo
di utilizzo basso; hanno però il difetto di "sparare nel mucchio",
rischiando di spendere molto tempo su dati poco rilevanti, e al
contempo mancare valori critici.

Non sarebbe bello poterli indirizzare sulle porzioni più interessanti
dello spazio dei dati, e intanto assicurarsi di esplorare certi valori
dimostratisi critici? È quello che fa il property-based testing, tra i
cui esponenti ci sono QuickCheck (Haskell) del 1999 e ScalaCheck del
2007.

C'è un gran bello strumento anche per Python: Hypothesis. Il suo
funzionamento è schematizzato in questa slide:



e l'ottima documentazione contiene un bel pezzo di advocacy:



Adesso non avete più scuse: andate e testate!


(I'm looking at you, Genropy. ;-) )

-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test statistici

[Pietro Battiston]

Il giorno mer, 15/10/2014 alle 23.07 +0100, enrico franchi ha scritto:
 
 
 2014-10-13 16:29 GMT+01:00 Mauro Alberti alberti@gmail.com:
 
 
 2014-10-13 15:16 GMT+02:00 enrico franchi
 enrico.fran...@gmail.com:
 
 2014-10-12 22:17 GMT+01:00 Mauro Alberti
 alberti@gmail.com:
 
 
 hai preso in considerazione R, che è il
 linguaggio statistico open-source più completo
 ed usato in accademia, e che volendo è anche
 interfacciabile con Python tramite rpy2? Per
 analisi statistiche è ottimo e fornisce tutte
 le possibili tecniche statistiche, credo ben
 più di Python..
 
 
 Ben piu' mi sembra eccessivo. Per inciso, sto
 vedendo un chiaro trend di Python che soppianta R per
 molte delle tradizionali roccaforti di R. Perche' e'
 semplicemente piu' facile lavorarci e piu' general
 purpose.
  
 
 
 Rimanendo ai numeri, per quel che son riuscito a ricuperare
 velocemente e facendo quindi la tara sia ai numeri sia alla
 loro interpretazione:
 - il repository ufficiale dei moduli R, CRAN - Packages
 (http://cran.r-project.org/web/packages/ ) riporta il numero
 di 5936 packages
 - in un repository Python non ufficiale, ma abbastanza
 completo di moduli (generici) Python, l'Unofficial Windows
 Binaries for Python Extension Packages
 (http://www.lfd.uci.edu/~gohlke/pythonlibs/) ho contato circa
 320 packages. Se i packages Python non considerati in questa
 collezione fossero un ordine di grandezza superiore a questo
 numero, il numero totale di moduli Python generali
 risulterebbe ancora inferiore a quello dei moduli R. 
 
 
 Non mi pare che questa cosa dica troppo. Potrei spendere parecchio
 tempo a spiegare il motivo per cui questo confronto numerico non abbia
 particolare senso, ma, sinceramente, non ne ho voglia perche' davvero,
 non credo di essere in grado di convincertene. Per inciso, il senso
 del mio discorso e' che vedo una grossissima crescita di Python
 nell'ambito da paper pubblicati (hey, ma io non seguo molti journal di
 statistica e matematica applicata, magari saro' biased... parecchia
 roba piu' o meno relativa al calderone buzzwordaro del BigData pero'
 si) e quello che vedo in startup e simili. Ovviamente dovrei trovare
 il modo di trovare hard data a sostanziare (il che e' complicato...
 sia perche' molti dati non sono pubblicamente disponibili, sia perche'
 molti altri sono particolarmente difficili da aggregare -- chesso',
 scoprire che nelle resources dei paper ci sono script in Python e/o
 che nel paper si menziona Python, *ma* in un contesto che fa intendere
 che appunto ci stanno facendo sopra statistica). Per cui teniamolo
 come gut feeling che non posso sostanziare... 
 
 
 Diciamo brevemente che stai comparando mele con pere e che quello che
 ci interessa e' una ricetta per fare la carbonara.
 
 
 In altre parole, il fatto che Python venga sempre piu' adottato per
 fare cose che prima si sarebbero fatte con R non necessariamente ha
 raffronto con l'intero numero di pacchetti prefabbricati che esistono
 per R (in cui stiamo contando, verosimilmente, anche pacchetti per
 fare richieste http (o qualunque altra cosa)) o con il numero di
 pacchetti utili per fare statistica in Python secondo l'autore della
 lista che riporti. 
 
 
 R è meno semplice di Python, è vero, ed anche più lento, p.e.
 nei plot. Però ha tuttora vari vantaggi, come una buona
 espressività statistica, una ottima e ricca documentazione dei
 moduli fatta dagli statistici che creano i packages, e poi un
 ambiente di plot integrato, il che semplifica parecchio la
 creazione di plot anche molto sofisticati. Per avere il
 corrispondente di quest'ultimo in Python ci si deve rivolgere
 ad IPython.
 
 
 E anche qui... niente da dire. Se ti trovi bene con R fai benissimo ad
 usare R e passare a Python o qualunque altra cosa ti sembra piu'
 opportuna. Per il resto, immagino che buona parte di chi voglia fare
 statistica in Python usi appunto tutto lo stack che c'e' a
 disposizione e di conseguenza non vedo problemi nel doversi rivolgere
 ad IPython; specie perche' ci sono almeno 3 distribuzioni di Python
 per fare questo tipo di cose che includono tutto il necessario (di cui
 almeno una interamente free).
  


Concordo moltissimo (da persona che ha cominciato a fare analisi
statistiche con vari altri linguaggi ma che sta convergendo a Python
anche per quello) sul fatto che il vantaggio enorme di Python sia che è

Re: [Python] Test statistici

[enrico franchi]

2014-10-13 16:29 GMT+01:00 Mauro Alberti alberti@gmail.com:



 2014-10-13 15:16 GMT+02:00 enrico franchi enrico.fran...@gmail.com:


 2014-10-12 22:17 GMT+01:00 Mauro Alberti alberti@gmail.com:


 hai preso in considerazione R, che è il linguaggio statistico
 open-source più completo ed usato in accademia, e che volendo è anche
 interfacciabile con Python tramite rpy2? Per analisi statistiche è ottimo e
 fornisce tutte le possibili tecniche statistiche, credo ben più di Python..


 Ben piu' mi sembra eccessivo. Per inciso, sto vedendo un chiaro trend
 di Python che soppianta R per molte delle tradizionali roccaforti di R.
 Perche' e' semplicemente piu' facile lavorarci e piu' general purpose.



 Rimanendo ai numeri, per quel che son riuscito a ricuperare velocemente e
 facendo quindi la tara sia ai numeri sia alla loro interpretazione:
 - il repository ufficiale dei moduli R, CRAN - Packages (
 http://cran.r-project.org/web/packages/ ) riporta il numero di 5936
 packages
 - in un repository Python non ufficiale, ma abbastanza completo di moduli
 (generici) Python, l'Unofficial Windows Binaries for Python Extension
 Packages (http://www.lfd.uci.edu/~gohlke/pythonlibs/) ho contato circa
 320 packages. Se i packages Python non considerati in questa collezione
 fossero un ordine di grandezza superiore a questo numero, il numero totale
 di moduli Python generali risulterebbe ancora inferiore a quello dei moduli
 R.


Non mi pare che questa cosa dica troppo. Potrei spendere parecchio tempo a
spiegare il motivo per cui questo confronto numerico non abbia particolare
senso, ma, sinceramente, non ne ho voglia perche' davvero, non credo di
essere in grado di convincertene. Per inciso, il senso del mio discorso e'
che vedo una grossissima crescita di Python nell'ambito da paper pubblicati
(hey, ma io non seguo molti journal di statistica e matematica applicata,
magari saro' biased... parecchia roba piu' o meno relativa al calderone
buzzwordaro del BigData pero' si) e quello che vedo in startup e simili.
Ovviamente dovrei trovare il modo di trovare hard data a sostanziare (il
che e' complicato... sia perche' molti dati non sono pubblicamente
disponibili, sia perche' molti altri sono particolarmente difficili da
aggregare -- chesso', scoprire che nelle resources dei paper ci sono script
in Python e/o che nel paper si menziona Python, *ma* in un contesto che fa
intendere che appunto ci stanno facendo sopra statistica). Per cui
teniamolo come gut feeling che non posso sostanziare...

Diciamo brevemente che stai comparando mele con pere e che quello che ci
interessa e' una ricetta per fare la carbonara.

In altre parole, il fatto che Python venga sempre piu' adottato per fare
cose che prima si sarebbero fatte con R non necessariamente ha raffronto
con l'intero numero di pacchetti prefabbricati che esistono per R (in cui
stiamo contando, verosimilmente, anche pacchetti per fare richieste http (o
qualunque altra cosa)) o con il numero di pacchetti utili per fare
statistica in Python secondo l'autore della lista che riporti.

R è meno semplice di Python, è vero, ed anche più lento, p.e. nei plot.
 Però ha tuttora vari vantaggi, come una buona espressività statistica, una
 ottima e ricca documentazione dei moduli fatta dagli statistici che creano
 i packages, e poi un ambiente di plot integrato, il che semplifica
 parecchio la creazione di plot anche molto sofisticati. Per avere il
 corrispondente di quest'ultimo in Python ci si deve rivolgere ad IPython.


E anche qui... niente da dire. Se ti trovi bene con R fai benissimo ad
usare R e passare a Python o qualunque altra cosa ti sembra piu' opportuna.
Per il resto, immagino che buona parte di chi voglia fare statistica in
Python usi appunto tutto lo stack che c'e' a disposizione e di conseguenza
non vedo problemi nel doversi rivolgere ad IPython; specie perche' ci sono
almeno 3 distribuzioni di Python per fare questo tipo di cose che includono
tutto il necessario (di cui almeno una interamente free).


 Che Python eroda R (e Matlab) è innegabile. D'altronde, rimanendo nel
 campo numerico, forse  in futuro Julia, grazie alla sua notevole velocità e
 semplicità, riuscirà a fare lo stesso con i tre precedenti linguaggi.


Io di mestiere faccio l'ingegnere (o per lo meno cosi' c'e' scritto nella
job description) e non l'indovino, per cui su quello che sara' il futuro
non so esprimermi.

Uno dei motivi per cui Python si sta allargando in favore di soluzioni
consolidate e' che Python e' un linguaggio general purpose *usato* come
linguaggio general purpose con una comunita' di persone che ci fanno,
appunto di tutto. Che vuole dire per dire che appunto tutte le volte che
devi incastrare intelligenza/statistica whatever in sistemi piu' complessi
sei piuttosto avvantaggiato. Le librerie per parlare con quasi qualunque
tipo di sistema ci sono gia', mantenute e usate da grosse community di
sviluppatori.

Se poi domani Julia si diffondera' a tal punto da condividere il tipo di

Re: [Python] Test statistici

[Valerio Maggio]

enrico franchi wrote:

 Ben piu' mi sembra eccessivo.

+1




___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test statistici

[Manlio Perillo]

2014-10-12 23:55 GMT+02:00 francesca senatore francesca.senat...@hotmail.it
:

 Grazie mille. Spero di riuscire a capire come fare.


Se non lo hai già fatto, ti consiglio di investire un pò di tempo per
imparare a programmare in Python:
https://docs.python.org/2/tutorial/index.html

Ci sono altri tutorial, se hai problemi chiedi pure.
Iniziare ad affrontare problemi complessi senza avere una buona conoscenza
di base significa solo perdere *molto* più tempo in seguito.

Ciao  Manlio


 Ciao
 Francesca
 --
 Date: Sun, 12 Oct 2014 23:48:36 +0200
 From: alberti@gmail.com
 To: python@lists.python.it
 Subject: Re: [Python] Test statistici



 2014-10-12 23:40 GMT+02:00 francesca senatore 
 francesca.senat...@hotmail.it:


 si ho scaricato anche questo pacchetto ma il mio problema è sempre quello
 non riesco a capire come indicare che determinati valori sono censored
 data, altri errori e altri ancora valori effettivi. Tu riesci a mandarmi
 una referenza o un link dove mi spiega queste cose?


 Premesso che di questo metodo non so nulla, alcuni dei numerosi link che
 ho trovato googlando survival analysis r sono:

 http://anson.ucdavis.edu/~hiwang/teaching/10fall/R_tutorial%201.pdf
 http://www.ms.uky.edu/~mai/rsurv.pdf

 http://www.openintro.org/download.php?file=survival_analysis_in_Rreferrer=/stat/surv.php

 oltre al generico:
 http://cran.r-project.org/web/views/Survival.html

 C'è anche almeno un video in Youtube..


 ciao



 ___ 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] Test statistici

[enrico franchi]

2014-10-12 22:17 GMT+01:00 Mauro Alberti alberti@gmail.com:


 hai preso in considerazione R, che è il linguaggio statistico open-source
 più completo ed usato in accademia, e che volendo è anche interfacciabile
 con Python tramite rpy2? Per analisi statistiche è ottimo e fornisce tutte
 le possibili tecniche statistiche, credo ben più di Python..


Ben piu' mi sembra eccessivo. Per inciso, sto vedendo un chiaro trend di
Python che soppianta R per molte delle tradizionali roccaforti di R.
Perche' e' semplicemente piu' facile lavorarci e piu' general purpose.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test statistici

[Mauro Alberti]

2014-10-13 15:16 GMT+02:00 enrico franchi enrico.fran...@gmail.com:


 2014-10-12 22:17 GMT+01:00 Mauro Alberti alberti@gmail.com:


 hai preso in considerazione R, che è il linguaggio statistico open-source
 più completo ed usato in accademia, e che volendo è anche interfacciabile
 con Python tramite rpy2? Per analisi statistiche è ottimo e fornisce tutte
 le possibili tecniche statistiche, credo ben più di Python..


 Ben piu' mi sembra eccessivo. Per inciso, sto vedendo un chiaro trend di
 Python che soppianta R per molte delle tradizionali roccaforti di R.
 Perche' e' semplicemente piu' facile lavorarci e piu' general purpose.



Rimanendo ai numeri, per quel che son riuscito a ricuperare velocemente e
facendo quindi la tara sia ai numeri sia alla loro interpretazione:
- il repository ufficiale dei moduli R, CRAN - Packages (
http://cran.r-project.org/web/packages/ ) riporta il numero di 5936 packages
- in un repository Python non ufficiale, ma abbastanza completo di moduli
(generici) Python, l'Unofficial Windows Binaries for Python Extension
Packages (http://www.lfd.uci.edu/~gohlke/pythonlibs/) ho contato circa 320
packages. Se i packages Python non considerati in questa collezione fossero
un ordine di grandezza superiore a questo numero, il numero totale di
moduli Python generali risulterebbe ancora inferiore a quello dei moduli R.

R è meno semplice di Python, è vero, ed anche più lento, p.e. nei plot.
Però ha tuttora vari vantaggi, come una buona espressività statistica, una
ottima e ricca documentazione dei moduli fatta dagli statistici che creano
i packages, e poi un ambiente di plot integrato, il che semplifica
parecchio la creazione di plot anche molto sofisticati. Per avere il
corrispondente di quest'ultimo in Python ci si deve rivolgere ad IPython.

Che Python eroda R (e Matlab) è innegabile. D'altronde, rimanendo nel campo
numerico, forse  in futuro Julia, grazie alla sua notevole velocità e
semplicità, riuscirà a fare lo stesso con i tre precedenti linguaggi.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test statistici

[Mauro Alberti]

2014-10-10 22:18 GMT+02:00 francesca senatore francesca.senat...@hotmail.it
:


 Ho specificato all'inizio della mail che sono alle prime armi. Ho iniziato
 da poco il dottorato in Astrofisica  Cosmologia e non conosco tutti i
 linguaggi di programmazione. Durante la tesi di laurea non impari proprio
 tanto.


Ciao Francesca,
hai preso in considerazione R, che è il linguaggio statistico open-source
più completo ed usato in accademia, e che volendo è anche interfacciabile
con Python tramite rpy2? Per analisi statistiche è ottimo e fornisce tutte
le possibili tecniche statistiche, credo ben più di Python..

mauro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test statistici

[francesca senatore]

Ciao Mauro, si ho scaricato anche questo pacchetto ma il mio problema è sempre 
quello non riesco a capire come indicare che determinati valori sono censored 
data, altri errori e altri ancora valori effettivi. Tu riesci a mandarmi una 
referenza o un link dove mi spiega queste cose?
Grazie mille 
Francesca 
Date: Sun, 12 Oct 2014 23:17:21 +0200
From: alberti@gmail.com
To: python@lists.python.it
Subject: Re: [Python] Test statistici


2014-10-10 22:18 GMT+02:00 francesca senatore francesca.senat...@hotmail.it:




Ho specificato all'inizio della mail che sono alle prime armi. Ho iniziato da 
poco il dottorato in Astrofisica  Cosmologia e non conosco tutti i linguaggi 
di programmazione. Durante la tesi di laurea non impari proprio tanto. 
 Ciao Francesca,
hai preso in considerazione R, che è il linguaggio statistico open-source più 
completo ed usato in accademia, e che volendo è anche interfacciabile con 
Python tramite rpy2? Per analisi statistiche è ottimo e fornisce tutte le 
possibili tecniche statistiche, credo ben più di Python..

mauro


___
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] Test statistici

[Manlio Perillo]

2014-10-10 19:39 GMT+02:00 francesca senatore francesca.senat...@hotmail.it
:

 Ciao a tutti,
 sono da poco (e per poco intendo veramente poco) nel mondo python. Sono
 alle prime armi e non me ne volete se non sono molto preparata.
 Al momento ho la necessità di eseguire dei test statistici
 (Kolmogorov-Smirnov test, Two Sample Tests, fit ai minimi quadrati) che
 erano inclusi in ASURV(analysis survival). Ho visto che python include
 questo pacchetto statistico.
 Il mio problema non sono tanto le routine in se per se (che mi sembrano
 facili) ma l'inserimento dati.



In generale dopo aver trovato le librerie che sembrano fare al caso tuo,
devi controllare la documentazione per vedere quali parametri accettano le
varie funzioni, e cosa rappresentano.


 I miei dati includono i famosi censored data (upper e lower limits) ed
 errori sulle misure. Io vorrei includere anche questi valori quando faccio
 correre questi test.
 Per essere più chiara mi scrivo un esempio (con dati a caso):




 from scipy import stats

  [...]


 slope, intercept, r_value, p_value, std_err = stats.linregress(x,y)

 Questa routine mi calcola il fit dandomi tutti i parametri che mi
 servono.  Nei miei set di dati ci sono upper limit, cioè non detection (i
 famosi censored data), che voglio tenere in considerazione nel fit. In
 aggiunta ho un altro set di dati che riguardano gli errori sulle y. Io
 voglio includere anche questi parametri ma non so come fare.


Come puoi vedere qui:
http://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.linregress.html#scipy.stats.linregress

la funzione linregress accetta solo due parametri.

Quindi devi usare un altra funzione o un altra libreria.


 Io usavo ASURV per fare cose di questo genere tenendo in considerazione
 gli upper oppure i lower limits e in questo caso indicavo le detection (i
 valori effettivamente calcolati) con 0 e con 1 le nondetection (upper
 limit). Cioè generavo un file con tre colonne dove la prima colonna
 indicava il tipo di valore.

 Con python ho visto che questo è possibile perchè include molti metodi
 statistici di ASURV ma non riesco a capire come inserire questi valori.


Quale funzione usavi in particolare?
Se è inclusa in scipy è possibile che abbia un nome simile.

 [...]


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Test statistici

[francesca senatore]

Ciao a tutti, sono da poco (e per poco intendo veramente poco) nel mondo 
python. Sono alle prime armi e non me ne volete se non sono molto preparata. Al 
momento ho la necessità di eseguire dei test statistici (Kolmogorov-Smirnov 
test, Two Sample Tests, fit ai minimi quadrati) che erano inclusi in 
ASURV(analysis survival). Ho visto che python include questo pacchetto 
statistico. Il mio problema non sono tanto le routine in se per se (che mi 
sembrano facili) ma l'inserimento dati. I miei dati includono i famosi censored 
data (upper e lower limits) ed errori sulle misure. Io vorrei includere anche 
questi valori quando faccio correre questi test. Per essere più chiara mi 
scrivo un esempio (con dati a caso):
Ho due vettori di dati: x=1, 2, 3, 4, 5, 6, 7 y=5, 4, 7, 8, 9, 11, 12 Ciò 
che voglio vedere è se c'è una correlazione lineare tra questi due set di dati. 
Ciò che faccio è una cosa di questo genere: from scipy import stats import 
numpy as np x=1, 2, 3, 4, 5, 6, 7 y=5, 4, 7, 8, 9, 11, 12 slope, intercept, 
r_value, p_value, std_err = stats.linregress(x,y) Questa routine mi calcola il 
fit dandomi tutti i parametri che mi servono.  Nei miei set di dati ci sono 
upper limit, cioè non detection (i famosi censored data), che voglio tenere in 
considerazione nel fit. In aggiunta ho un altro set di dati che riguardano gli 
errori sulle y. Io voglio includere anche questi parametri ma non so come fare. 
Io usavo ASURV per fare cose di questo genere tenendo in considerazione gli 
upper oppure i lower limits e in questo caso indicavo le detection (i valori 
effettivamente calcolati) con 0 e con 1 le nondetection (upper limit). Cioè 
generavo un file con tre colonne dove la prima colonna indicava il tipo di 
valore. Con python ho visto che questo è possibile perchè include molti metodi 
statistici di ASURV ma non riesco a capire come inserire questi valori. Spero 
di essere stata chiara.  
Se qualcuno di voi ha competenze di questo genere e sa come far girare queste 
routine in python includendo censored data e errori sulle misure può aiutarmi?
Grazie mille 
Chicca___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test statistici

[Valerio Maggio]

francesca senatore wrote:

 Ciao a tutti, 
 sono da poco (e per poco intendo veramente poco) nel mondo python. Sono alle 
 prime armi e non me ne volete se non sono molto preparata. 

Ciao Francesca, 
 benvenuta! :)

 Al momento ho la necessità di eseguire dei test statistici 
 (Kolmogorov-Smirnov test, Two Sample Tests, fit ai minimi quadrati) che erano 
 inclusi in ASURV(analysis survival). Ho visto che python include questo 
 pacchetto statistico. 

Che intendi? ASURV?

Che roba è? Io ho trovato questo: http://python-asurv.sourceforge.net
È lui?

In ogni caso guardando mi pare di capire che si tratta di un software per dati 
astronimici/astro fisici[1]. Corretto?

Nel caso il tuo dominio fosse quello, ti segnalo questi due progetti:

**AstroPy**: http://www.astropy.org
**AstroML**: http://www.astroml.org

Sono ben documentati e molto supportati dalla comunità… certamente meglio di 
quel porting indicato poco prima.. anyway..

——
[1]: http://www.astrostatistics.psu.edu/statcodes/


 Il mio problema non sono tanto le routine in se per se (che mi sembrano 
 facili) ma l'inserimento dati. I miei dati includono i famosi censored data 
 (upper e lower limits) ed errori sulle misure. Io vorrei includere anche 
 questi valori

ok, il tuo problema è chiaro (a parte che non capisco perché vuoi includere i 
censored data nel calcolo del fitting.. ma tant'è…. del resto, non hai 
specificato il dominio.. :P)

 quando faccio correre questi test. 

effettiva run, in inglese, significa correre… :D (kiddin')


 from scipy import stats 
 
 import numpy as np 
 
 x=1, 2, 3, 4, 5, 6, 7 
 
 y=5, 4, 7, 8, 9, 11, 12 

vabeh, diciamo che questo non è esattamente codice Python.. :P

 
 slope, intercept, r_value, p_value, std_err = stats.linregress(x,y) 
 
 Questa routine mi calcola il fit dandomi tutti i parametri che mi servono.  
 Nei miei set di dati ci sono upper limit, cioè non detection (i famosi 
 censored data), che voglio tenere in considerazione nel fit. In aggiunta ho 
 un altro set di dati che riguardano gli errori sulle y. Io voglio includere 
 anche questi parametri ma non so come fare. 
 
 Io usavo ASURV per fare cose di questo genere tenendo in considerazione gli 
 upper oppure i lower limits e in questo caso indicavo le detection (i valori 
 effettivamente calcolati) con 0 e con 1 le nondetection (upper limit). Cioè 
 generavo un file con tre colonne dove la prima colonna indicava il tipo di 
 valore. 
 
 Con python ho visto che questo è possibile perchè include molti metodi 
 statistici di ASURV ma non riesco a capire come inserire questi valori. 

Io però a questo punto non ho capito quale sia **veramente** il tuo problema..

In ogni caso, penso che questo possa esserti utile: 
https://www.wakari.io/nb/pybokeh/Weibull_Analysis#part2
Credo sia proprio un esempio di analisi che si avvicina a ciò che intendi fare…

In generale, poi, ti segnalo anche `statsmodel`: 
https://github.com/statsmodels/statsmodels

Oltre ad estendere le funzionalità di `scipy.stats`, dovrebbe già contenere dei 
metodi per l'analisi con *suspended* data...


HTH
Valerio

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test statistici

[francesca senatore]

Ciao Valerio, grazie per la tua risposta.
Che intendi? ASURV?
Che roba è? Io ho trovato questo: http://python-asurv.sourceforge.netÈ lui?
In ogni caso guardando mi pare di capire che si tratta di un software per dati 
astronimici/astro fisici[1]. Corretto?
Nel caso il tuo dominio fosse quello, ti segnalo questi due progetti:
**AstroPy**: http://www.astropy.org**AstroML**: http://www.astroml.org
Sono ben documentati e molto supportati dalla comunità… certamente meglio di 
quel porting indicato poco prima.. anyway..
Si è lui. 

effettiva run, in inglese, significa correre… :D (kiddin')
So come si dice in inglese! La prossima volta sarò più precisa! :D

from scipy import stats import numpy as np x=1, 2, 3, 4, 5, 6, 7 y=5, 4, 7, 
8, 9, 11, 12 
vabeh, diciamo che questo non è esattamente codice Python.. :P
Ho specificato all'inizio della mail che sono alle prime armi. Ho iniziato da 
poco il dottorato in Astrofisica  Cosmologia e non conosco tutti i linguaggi 
di programmazione. Durante la tesi di laurea non impari proprio tanto. 
In ogni caso, penso che questo possa esserti utile: 
https://www.wakari.io/nb/pybokeh/Weibull_Analysis#part2Credo sia proprio un 
esempio di analisi che si avvicina a ciò che intendi fare…
In generale, poi, ti segnalo anche `statsmodel`: 
https://github.com/statsmodels/statsmodels
Oltre ad estendere le funzionalità di `scipy.stats`, dovrebbe già contenere dei 
metodi per l'analisi con *suspended* data...
Grazie mille. Spero che possano aiutarmi
Ciao 
Chicca



From: valerio.mag...@gmail.com
Date: Fri, 10 Oct 2014 20:07:22 +0200
To: python@lists.python.it
Subject: Re: [Python] Test statistici


francesca senatore wrote:Ciao a tutti, sono da poco (e per poco intendo 
veramente poco) nel mondo python. Sono alle prime armi e non me ne volete se 
non sono molto preparata. 
Ciao Francesca,  benvenuta! :)
Al momento ho la necessità di eseguire dei test statistici (Kolmogorov-Smirnov 
test, Two Sample Tests, fit ai minimi quadrati) che erano inclusi in 
ASURV(analysis survival). Ho visto che python include questo pacchetto 
statistico. 
Che intendi? ASURV?
Che roba è? Io ho trovato questo: http://python-asurv.sourceforge.netÈ lui?
In ogni caso guardando mi pare di capire che si tratta di un software per dati 
astronimici/astro fisici[1]. Corretto?
Nel caso il tuo dominio fosse quello, ti segnalo questi due progetti:
**AstroPy**: http://www.astropy.org**AstroML**: http://www.astroml.org
Sono ben documentati e molto supportati dalla comunità… certamente meglio di 
quel porting indicato poco prima.. anyway..
——[1]: http://www.astrostatistics.psu.edu/statcodes/

Il mio problema non sono tanto le routine in se per se (che mi sembrano facili) 
ma l'inserimento dati. I miei dati includono i famosi censored data (upper e 
lower limits) ed errori sulle misure. Io vorrei includere anche questi valori 
ok, il tuo problema è chiaro (a parte che non capisco perché vuoi includere i 
censored data nel calcolo del fitting.. ma tant'è…. del resto, non hai 
specificato il dominio.. :P)
quando faccio correre questi test. 
effettiva run, in inglese, significa correre… :D (kiddin')

from scipy import stats import numpy as np x=1, 2, 3, 4, 5, 6, 7 y=5, 4, 7, 
8, 9, 11, 12 
vabeh, diciamo che questo non è esattamente codice Python.. :P
slope, intercept, r_value, p_value, std_err = stats.linregress(x,y) Questa 
routine mi calcola il fit dandomi tutti i parametri che mi servono.  Nei miei 
set di dati ci sono upper limit, cioè non detection (i famosi censored data), 
che voglio tenere in considerazione nel fit. In aggiunta ho un altro set di 
dati che riguardano gli errori sulle y. Io voglio includere anche questi 
parametri ma non so come fare. Io usavo ASURV per fare cose di questo genere 
tenendo in considerazione gli upper oppure i lower limits e in questo caso 
indicavo le detection (i valori effettivamente calcolati) con 0 e con 1 le 
nondetection (upper limit). Cioè generavo un file con tre colonne dove la prima 
colonna indicava il tipo di valore. Con python ho visto che questo è possibile 
perchè include molti metodi statistici di ASURV ma non riesco a capire come 
inserire questi valori. 
Io però a questo punto non ho capito quale sia **veramente** il tuo problema..
In ogni caso, penso che questo possa esserti utile: 
https://www.wakari.io/nb/pybokeh/Weibull_Analysis#part2Credo sia proprio un 
esempio di analisi che si avvicina a ciò che intendi fare…
In generale, poi, ti segnalo anche `statsmodel`: 
https://github.com/statsmodels/statsmodels
Oltre ad estendere le funzionalità di `scipy.stats`, dovrebbe già contenere dei 
metodi per l'analisi con *suspended* data...

HTHValerio

___
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] Test, test e ancora test, voi cosa usate?

[Dario Bertini]

Giusto l'altra sera mi sono visto questo talk:

https://www.youtube.com/watch?v=zi0rHwfiX1Q

(è stato ripreso all'ultima Clojure/West, ma non preoccupatevi... il
codice è in Erlang :P )

È di uno degli autori di QuickCheck, che già ho usato... ma che questa
presentazione mi ha fatto apprezzare ancora meglio

Il nocciolo dell'idea è: non scrivere i test, generali!

Ce ne sono diversi porting per Python, quello più attivo è forse
questo: https://bitbucket.org/t2y/pytest-quickcheck/

(non l'ho usato, quindi se avete una versione migliore di quickcheck
da consigliare fatevi avanti)

-- 
xmpp: berda...@gmail.com
bitmessage: BM-2cTYXfGiSTsnx3righ6aHcJSWe4MV17jDP
gpg fingerprint: 3F8D53518012716C4EEF7DF67B498306B3BF75A0 (used just
for signing commits)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test, test e ancora test, voi cosa usate?

[Daniele Varrazzo]

On 2014-04-15 11:39, Dario Bertini wrote:

Giusto l'altra sera mi sono visto questo talk:

https://www.youtube.com/watch?v=zi0rHwfiX1Q

(è stato ripreso all'ultima Clojure/West, ma non preoccupatevi... il
codice è in Erlang :P )

È di uno degli autori di QuickCheck, che già ho usato... ma che 
questa

presentazione mi ha fatto apprezzare ancora meglio

Il nocciolo dell'idea è: non scrivere i test, generali!

Ce ne sono diversi porting per Python, quello più attivo è forse
questo: https://bitbucket.org/t2y/pytest-quickcheck/

(non l'ho usato, quindi se avete una versione migliore di quickcheck
da consigliare fatevi avanti)


Un mio amico ne stava scrivendo uno, ma non ho seguito quanto è andato 
avanti


https://github.com/davidedelvento/qc

-- Daniele
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test, test e ancora test, voi cosa usate?

[Carlo Miron]

Il 15 aprile 2014 12:47, Daniele Varrazzo p...@develer.com ha scritto:

 On 2014-04-15 11:39, Dario Bertini wrote:
 (non l'ho usato, quindi se avete una versione migliore di quickcheck
 da consigliare fatevi avanti)

 Un mio amico ne stava scrivendo uno, ma non ho seguito quanto è andato
 avanti
 https://github.com/davidedelvento/qc

mancava, in effetti :P

©

-- 
 :**THE BEER-WARE LICENSE** (Revision 42):
   ``miron AT python.it`` wrote this mail. As long as you retain this notice
   you can do whatever you want with this stuff. If we meet some day, and you
   think this stuff is worth it, you can buy me a beer in return.

   --*Carlo Miron*

  ..
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test, test e ancora test, voi cosa usate?

[Daniele Varrazzo]

On 2014-04-15 13:28, Carlo Miron wrote:
Il 15 aprile 2014 12:47, Daniele Varrazzo p...@develer.com ha 
scritto:



On 2014-04-15 11:39, Dario Bertini wrote:
(non l'ho usato, quindi se avete una versione migliore di 
quickcheck

da consigliare fatevi avanti)


Un mio amico ne stava scrivendo uno, ma non ho seguito quanto è 
andato

avanti
https://github.com/davidedelvento/qc


mancava, in effetti :P


As in ce ne sono almeno 347 implementazioni? :) Non ne so molto: QC è 
stato hip nel mondo erlang per un po' ma a noi non ha acchiappato 
molto...


-- Daniele



___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test, test e ancora test, voi cosa usate?

[Carlo Miron]

Il 15 aprile 2014 14:34, Daniele Varrazzo p...@develer.com ha scritto::

 On 2014-04-15 13:28, Carlo Miron wrote:
 mancava, in effetti :P

 As in ce ne sono almeno 347 implementazioni? :)

Beh, meno che di web framework, e di packet manager, in effetti.

©

-- 
 :**THE BEER-WARE LICENSE** (Revision 42):
   ``miron AT python.it`` wrote this mail. As long as you retain this notice
   you can do whatever you want with this stuff. If we meet some day, and you
   think this stuff is worth it, you can buy me a beer in return.

   --*Carlo Miron*

  ..
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test, test e ancora test, voi cosa usate?

[Nicola Larosa]

Simone Dalla wrote:

Conoscete [...] altri tool che possono completare, ampliare,
aiutare una pratica spinta del TDD?


Behavior Driven Development
http://pythonhosted.org/behave/philosophy.html

Scrivi i test funzionali insieme ai casi d'uso in linguaggio umano, e
ti ritrovi documentazione chiara e sempre aggiornata. L'uovo di Colombo.

Behave, Robot Framework, Pyccuracy. Cetrioli e rubini non richiesti. ;-)

Per i test d'integrazione e d'unità, sempre necessari, si usano altri
strumenti.

--
Nicola 'tekNico' Larosa http://www.tekNico.net/

Urgullibl: The continent with the highest average education
level is Antarctica.
thepresidentsturtle: Those penguins are really smart though.
  Not really fair to compare us to them.
Neebat: They invented Linux, the best operating system.
 Then they gave it to Linus Torvalds, their prophet.
 - Comments on a Reddit discussion, February 2014

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Test Regular Expressions

[Simone Federici]

Ciao,

ho una serie di espressioni regolari e vorrei trovare il modo di fornire
dinamicamente all'utente
delle stringhe per testarle.

c'è un modo furbo per ottenere una stringa che fa il match di una
espressione regolare a partire dalla espressione regolare stessa? tenendo
conto che non la conosciamo a priori?

qualcuno ci si è mai scontrato?

chiaramente la strada lunga e tortuosa è quella di parsarsela :-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test Regular Expressions

[Andrea Francia]

On Thu, Apr 12, 2012 at 10:58, Simone Federici s.feder...@gmail.com wrote:

 c'è un modo furbo per ottenere una stringa che fa il match di una
 espressione regolare a partire dalla espressione regolare stessa? tenendo
 conto che non la conosciamo a priori?


Boooh?
Se non ci sono parentesi ne pipe allora basta prendere l'espressione
regolare e togliere tutti i *, ?.
Se ci sono parentesi diventa difficile :-(

Ciao

-- 
Andrea Francia http://www.andreafrancia.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test Regular Expressions

[Marco Mariani]

2012/4/12 Andrea Francia and...@andreafrancia.it

Se non ci sono parentesi ne pipe allora basta prendere l'espressione
 regolare e togliere tutti i *, ?.
 Se ci sono parentesi diventa difficile :-(


forse questo puo' aiutare?

http://stackoverflow.com/questions/492716/reversing-a-regular-expression-in-python
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test Regular Expressions

[Simone Federici]

grazie beri ho trovato questa:
https://bitbucket.org/leapfrogdevelopment/rstr/


dopodiche la uso cosi dento un model

def test_url(self):
return a target='_blank' href='%s'Test URL/a % reverse(
regex_channel,
kwargs={'channel_url' : rstr.xeger(self.url)})
test_url.allow_tags = True

e ottengo una url da testare direttamente nell'admin
fondamentalmente il channel è un dispatcher dinamico

ciao
S


2012/4/12 Marco Mariani bir...@gmail.com

 2012/4/12 Andrea Francia and...@andreafrancia.it

 Se non ci sono parentesi ne pipe allora basta prendere l'espressione
 regolare e togliere tutti i *, ?.
 Se ci sono parentesi diventa difficile :-(


 forse questo puo' aiutare?


 http://stackoverflow.com/questions/492716/reversing-a-regular-expression-in-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] Test Regular Expressions

[Simone Federici]

2012/4/12 Simone Federici s.feder...@gmail.com

 grazie beri


cazzarola, vedi Freud !!
regexp == beri


grazie a tutti
e grazie Marco Mariani :-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test Regular Expressions

[Marco Beri]

2012/4/12 Simone Federici s.feder...@gmail.com

 2012/4/12 Simone Federici s.feder...@gmail.com

 grazie beri


 cazzarola, vedi Freud !!
 regexp == beri



:-)))
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Test mailserver antivirus

[Simone Federici]

Ragazzi ho bisogno di testare l'antivirus di alcuni server, (sotto carico,
ma è ininfluente sul topic)

la mia idea è usare le signatures dei virus di Clamav
e bombardare il mailserver.

il punto è che ho solo le signatures, quindi non ho i virus, quindi un
modo per creare degli attachments on the fly
che come firma abbiano quelle di clamav ce ne sono? qualcuno conosce una
easy way?

PS (alternativa)
oppure qualcuno ha windows e mi posta i suoi file dentro system32? tanto
:-P

S
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test su locale

[Manlio Perillo]

Il 29/06/2010 16:09, Pietro Battiston ha scritto:
 Ohilà,
 
 sapreste suggerirmi un modo furbo per fare dei test che giochino con
 le locale e siano portabili?
 
 
 Questo breve test:
 
 http://trac.gispython.org/lab/browser/Shapely/branches/1.2/shapely/tests/wkt_locale.txt
 
 è scritto per verificare che shapely - la libreria di cui fa parte - si
 comporti bene anche con locale in cui il separatore decimale è una
 virgola. Il problema è che il test ovviamente fallisce sui sistemi in
 cui la locale prescelta, 'pt_BR.UTF-8', non è installata.
 
 Per quel che ne so, l'unica locale che si può presumere installata
 ovunque è C, che però è inutile per quel che riguarda il test del
 separatore decimale.
 
 Idee? Non sono nemmeno riuscito a capire se esiste un modo (che non sia
 ravanare tra i file di sistema) per capire _quali_ locale sono
 disponibili...
 

Non utilizzare il locale di sistema, ed usa invece CLDR
http://cldr.unicode.org/

implementato in Babel:
http://babel.edgewall.org/



Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test su locale

[Marco Mariani]

On Tue, 2010-06-29 at 16:09 +0200, Pietro Battiston wrote:

 Idee? Non sono nemmeno riuscito a capire se esiste un modo (che non sia
 ravanare tra i file di sistema) per capire _quali_ locale sono
 disponibili...

su linux, 'locale -a'



___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test su locale

[Pietro Battiston]

Il giorno mar, 29/06/2010 alle 17.17 +0200, Manlio Perillo ha scritto:
 Il 29/06/2010 16:09, Pietro Battiston ha scritto:
  Ohilà,
  
  sapreste suggerirmi un modo furbo per fare dei test che giochino con
  le locale e siano portabili?
  
  
  Questo breve test:
  
  http://trac.gispython.org/lab/browser/Shapely/branches/1.2/shapely/tests/wkt_locale.txt
  
  è scritto per verificare che shapely - la libreria di cui fa parte - si
  comporti bene anche con locale in cui il separatore decimale è una
  virgola. Il problema è che il test ovviamente fallisce sui sistemi in
  cui la locale prescelta, 'pt_BR.UTF-8', non è installata.
  
  Per quel che ne so, l'unica locale che si può presumere installata
  ovunque è C, che però è inutile per quel che riguarda il test del
  separatore decimale.
  
  Idee? Non sono nemmeno riuscito a capire se esiste un modo (che non sia
  ravanare tra i file di sistema) per capire _quali_ locale sono
  disponibili...
  
 
 Non utilizzare il locale di sistema, ed usa invece CLDR
 http://cldr.unicode.org/
 
 implementato in Babel:
 http://babel.edgewall.org/
 

Uhm... se ho capito bene, intendi che non è da cambiare (solo) il test,
ma la funzione testata.

Ma sempre se ho capito bene, il problema è che la rappresentazioni dei
numeri è fornita da una libreria C sottostante e indipendente.

E se ho capito miracolosamente bene, babel lo devo decidere di
utilizzare esplicitamente io quando rappresento stampo un numero/una
data, cosa che invece quella libreria python non fa affatto...

Quindi la risposta sarebbe che senza andare a cambiare il codice C, un
test come quello semplicemente non può esistere?

Pietro

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test su locale

[Manlio Perillo]

Il 29/06/2010 17:54, Pietro Battiston ha scritto:
 Il giorno mar, 29/06/2010 alle 17.17 +0200, Manlio Perillo ha scritto:
 Il 29/06/2010 16:09, Pietro Battiston ha scritto:
 Ohilà,

 sapreste suggerirmi un modo furbo per fare dei test che giochino con
 le locale e siano portabili?

 [...]

 Idee? Non sono nemmeno riuscito a capire se esiste un modo (che non sia
 ravanare tra i file di sistema) per capire _quali_ locale sono
 disponibili...


 Non utilizzare il locale di sistema, ed usa invece CLDR
 http://cldr.unicode.org/

 implementato in Babel:
 http://babel.edgewall.org/

 
 Uhm... se ho capito bene, intendi che non è da cambiare (solo) il test,
 ma la funzione testata.
 

Se devi scrivere codice nuovo o se il codice è tuo (ed è scritto in
Python), probabilmente è la scelta migliore.

 Ma sempre se ho capito bene, il problema è che la rappresentazioni dei
 numeri è fornita da una libreria C sottostante e indipendente.
 

Il problema è che quel modulo è un wrapper di una libreria C, che quindi
accede alle informazioni del locale in C.

In questo caso c'è poco da fare; devi installare sul sistema tutti i
locale che ti servono.



Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] test [was: Re: Come fareste voi?]

[Alessandro Dentella]

  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.

non è che cerchi contrapposizione dove non c'è? Mi pare che le differenze
fra il mio ed il tuo punti di vista siano relativamente piccole.

La mia frase che cito era per confermare che anche io trovo una flessibilità
maggiore in *unittest* e simili (nose, py.test migliorano in vario modo ma non
stravolgono il concetto degli unittest) ed a questi non rinuncerei, ma non
rinuncerei neanche ai doctest quando voglio qualcosa che assomigli di più
alla documentazione.

[Per inciso non metto i test nelle docstring ma in file separati, proprio
 perché son convinto che una docstring troppo lunga non sia comoda.]

sandro
*:-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] test [was: Re: Come fareste voi?]

[Daniele Varrazzo]

On Sat, 20 Feb 2010 09:57:21 +0100, Alessandro Dentella san...@e-den.it
wrote:

 non è che cerchi contrapposizione dove non c'è? Mi pare che le
differenze
 fra il mio ed il tuo punti di vista siano relativamente piccole.

Scusami, ero un po' lanciato ;)

A presto, 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] test [was: Re: Come fareste voi?]

[Simone Federici]

A me piacciono i doctest, ovviamente li uso giusto per metodi semplisiccimi,
non devono superare le 4 righe :-D


Simone Federici
---
Software Architect



2010/2/20 Daniele Varrazzo p...@develer.com

 On Sat, 20 Feb 2010 09:57:21 +0100, Alessandro Dentella san...@e-den.it
 wrote:

  non è che cerchi contrapposizione dove non c'è? Mi pare che le
 differenze
  fra il mio ed il tuo punti di vista siano relativamente piccole.

 Scusami, ero un po' lanciato ;)

 A presto, 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

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] test [was: Re: Come fareste voi?]

[Daniele Varrazzo]

On Fri, 19 Feb 2010 19:36:02 +0100, Alessandro Dentella san...@e-den.it
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=1502view=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] test [was: Re: Come fareste voi?]

[Manlio Perillo]

-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?]

[Daniele Varrazzo]

On Fri, 19 Feb 2010 22:51:12 +0100, Alessandro Dentella san...@e-den.it
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

[Python] Test se una variabile d'istanza esiste

[michele]

Ciao,
come posso testare se una variabile d'istanza di una classe esiste?

Ho provato così:

class Foo(object):
  def bar(self):
   try:
 self.baz
 # qui posso usare baz

   except AttributeError:
 print 'la variabile non esiste, la creo'


Non sono sicuro che sia il metodo giusto, però.
Avete qualche idea?

Vi ringrazio



___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test se una variabile d'istanza esiste

[Daniele Varrazzo]

On Fri, 24 Oct 2008 18:54:57 +0200, [EMAIL PROTECTED] wrote:
 Ciao,
 come posso testare se una variabile d'istanza di una classe esiste?

hasattr(self, 'baz')

 Ho provato così:
 
 class Foo(object):
   def bar(self):
try:
  self.baz
  # qui posso usare baz
 
except AttributeError:
  print 'la variabile non esiste, la creo'
 
 
 Non sono sicuro che sia il metodo giusto, però.

Credo che hasattr sia implementato grossomodo alla stessa maniera :) 

-- 
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] Test se una variabile d'istanza esiste

[Simone]

Il venerdì 24 ottobre 2008 18:54:57 [EMAIL PROTECTED] ha scritto:

 class Foo(object):
   def bar(self):
try:
  self.baz
  # qui posso usare baz

except AttributeError:
  print 'la variabile non esiste, la creo'


 Non sono sicuro che sia il metodo giusto, però.
 Avete qualche idea?

hasattr(Foo, baz)

PS: Scusate per l'email sbagliata di prima :)
--
Simone
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test se una variabile d'istanza esiste

[Simone]

Il venerdì 24 ottobre 2008 18:54:57 [EMAIL PROTECTED] ha scritto:
 Ciao,
 come posso testare se una variabile d'istanza di una classe esiste?

 Ho provato così:

 class Foo(object):
   def bar(self):
try:
  self.baz
  # qui posso usare baz

except AttributeError:
  print 'la variabile non esiste, la creo'


 Non sono sicuro che sia il metodo giusto, però.
 Avete qualche idea?

 Vi ringrazio



 ___
 Python mailing list
 Python@lists.python.it
 http://lists.python.it/mailman/listinfo/python

-- 
--
Simone
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python