Re: [Python] __debug__ e EAFP

[Paolo Melchiorre]

On Thu, May 12, 2016, 13:40 Marco Santamaria wrote:

> Il giorno 12 maggio 2016 10:24, Carlos Catucci ha scritto:
>
>> Se ho ben capito Martelli ha detto che si usano in sviluppo
>> testing solamente.
>>
>
> Comunque mi pare che in questo thread la questione sia stata sviscerata ed
> è chiaro che gli assert nel codice in produzione non siano un delitto, a
> patto di non basare il funzionamento sul try degli AssertionError.
>

In realtà anche nel suo talk all'ultimo Pycon7 ha ribadito il suo invito a
non usare assert in un contesto di produzione.

Nel mio tweet relativo al talk trovate 2 link di Martelli stesso:
https://twitter.com/pauloxnet/status/721762608559341568?s=09

Paolo

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

Re: [Python] [Meta-lista] Messaggi in solo testo

[Simone Federici]

Nicola Larosa:
>
> No, sei solo un po' duro de capoccia. ;-)


tu dici? mi sembra come il discorso del bue.

> quando mandi una mail da gmail, arrivano 2 messaggi con 2 content
> > type diversi. html e plain text.
>
> E invece Carlos è riuscito a convincere GMail a mandare messaggi in
> solo testo. :-)


già, ma io non ho nessuna intenzione di farlo
:-)


> > chi ha bisogno di vedere le email evitando l'html può configurarsi
> > ad hoc il suo client
>
> Vero se il mittente manda l'email in MIME multipart con sia il testo
> che l'HTML. Alcuni client mandano solo HTML.


gmail manda la mail "multipart" con entrambi i content type.

se non vi sta bene, amen.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Pesaro Pythonic HackClub

[Massimiliano della Rovere]

Io sto cercando di organizzare un incontro a Senigallia, e sono in contatto
con alcuni pythonisti incontrati alla PyCon. Alcuni sono su DevMarche,
quindi metti un annuncio lì.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Pesaro Pythonic HackClub

[Giovanni Costantini]

Ciao a tutti,
sto tentando di oganizzare un Python users group a Pesaro. La
finalita' del gruppo e' quella di vedersi ed accrescere le competenze
di programmazione in Python di tutti gli aderenti al gruppo.

Per gestire la fase di startup ho aperto una pagina meetup
raggiungibile all'indirizzo :
http://www.meetup.com/it-IT/Pesaro-Pythonists/

Se sei della zona ed hai voglia di unirti, sarai il benvenuto.

Al momento io sono l'unico iscritto al gruppo. :)

Grazie per aver voluto leggere questo messaggio,

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

Re: [Python] __debug__ e EAFP

[Marco Santamaria]

Il giorno 12 maggio 2016 10:24, Carlos Catucci 
ha scritto:

> Se ho ben capito Martelli ha detto che si usano in sviluppo testing
> solamente. Oppure ho frainteso il post di Marco (Santamaria)?
>

Se non ricordo male, la morale era quella. Magari possiamo aspettare che
venga pubblicato il video e ricontrollare.
Comunque mi pare che in questo thread la questione sia stata sviscerata ed
è chiaro che gli assert nel codice in produzione non siano un delitto, a
patto di non basare il funzionamento sul try degli AssertionError.

-- 
|_|0|_|
|_|_|0|
|0|0|0|
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] __debug__ e EAFP

[Giovanni Porcari]

> Il giorno 11 mag 2016, alle ore 23:33, Roberto Polli  ha 
> scritto:
> 
> Il 11 maggio 2016 16:31, Pietro Battiston  ha 
> scritto:
>> ... condensare ...
>> 
>> if not civico.isdigit():
>>raise ValueError("Il numero civico deve essere numerico")
>> 
>> in
>> 
>> assert(civico.isdigit()) "Il numero civico deve essere numerico"
>> 
> Uso assert se il controllo:
> 
>  - non deve influire sul flusso del programma;
>  - rappresenta condizioni inaspettate e quindi un bug del programma;
>  - come placeholder nelle fasi preliminari - chiarito meglio il
> flusso li sostituisco con eccezioni;
> 
> eg.


Io invece uso le assert per rendere più leggibili degli errori
che può commettere lo sviluppatore ma che non saranno mai in produzione.

Ad esempio, gestendo una tabella in genropy devo avere una risorsa di form
associata. Supponiamo che lo sviluppatore metta come nome della form 
'Miabellaform'
e che poi nel codice chieda di caricare la risorsa 'Miabelaform'.
Potrei nel loader della risorsa mettere una try e sollevare un'eccezione
se la risorsa cercata non esiste. Ma onestamente un problema simile NON capita 
in produzione,
e quindi la try è inutile. Però se lo sviluppatore commette l'errore che dicevo 
prima,
si trova una pagina bianca e magari non capisce perchè. 
Quindi se nel loader posso mettere un assert che se non trova la risorsa mi 
dica che 
la risorsa 'Miabelaform' non esiste.

Questo tipo di uso è a mio avviso, perfetto per un'assert.

Ciao

G.

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

Re: [Python] __debug__ e EAFP

[Carlos Catucci]

2016-05-12 10:19 GMT+02:00 Nicola Larosa :
> Mai visto nessuno farlo, checché ne dica Martelli (ciao Alex :-) ).

Se ho ben capito Martelli ha detto che si usano in sviluppo testing
solamente. Oppure ho frainteso il post di Marco (Santamaria)?

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

Re: [Python] __debug__ e EAFP

[Nicola Larosa]

Marco Giusti wrote:
> Onestamente mi chiedo quante persone utilizzino l'opzione -O in
> produzione. Un piccolo grep in /usr/bin ha confermato le mie
> aspettative.

Mai visto nessuno farlo, checché ne dica Martelli (ciao Alex :-) ).

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

Re: [Python] __debug__ e EAFP

[Marco Giusti]

Vorrei rispondere a Pietro prima e aggiungere una nota a quanto detto da
Enrico alla fine.

> > Cioe'... mi passi una lista vuota invece che una piena?
> > AssertionError.
> > Mi passi un intero invece di una stringa? AssertionError.
> > Una chiamata http mi torna 503? AssertionError.
> > 
> > E poi chi lo debugga sto coso?
> > 
> 
> Sono più o meno d'accordo con la risposta di Luca, ma in più... a me il
> messaggio di errore "assert" sembrava proprio una meraviglia per il
> debugging... sostanzialmente mi piaceva condensare (esempio stupido) un
> 
> if not civico.isdigit():
>     raise ValueError("Il numero civico deve essere numerico")
> 
> in
> 
> assert(civico.isdigit()) "Il numero civico deve essere numerico"
> 
> senza perdere "capacità informativa".
> 
> Ciò detto, OK, ora che ho capito il funzionamento di "-O" tutti questi
> sono ragionamenti puramente ipotetici, anche perché è chiaro che vista
> da questo punto di vista un qualsiasi codice altrui che ti restituisca
> una AssertionError è bacato.

Forse non aggiungo niente a quanto detto e la questione è chiara e
limpida a tutti quanti, ma trovo le asserzioni molto comode soprattutto
nei motodi privati ovvero tutti quei quei metodicini che iniziano per
"_" e che sono l'implementazione del programma. Con le asserzioni puoi
controllare pre e post condizioni e (mi) aiutano a mettere un po' di
ordine nella logica di idee in fase di sviluppo. Questo è ben differente
dal lanciare un bel ValueError nella factorial(), il metodo factorial
_è_ l'api. Sicuramente l'utente è ben più felice di dover risolvere il
seguente errore: "ValueError: factorial() not defined for negative
values" piuttosto che avere a volte un AssertionError e a volte un
valore sballato di ritorno.

Per esempio io non mi scioccherei di trovare il seguente codice in una
libreria che implementa un oggetto di tipo lista:

def append(self, value):
l = len(self)
self._append_real(value)
assert len(self) == l + 1
assert self[-1] == value

Se tre linee su quattro sono inutili in fase di utilizzo, possono essere
molto utili in fase di test. Io stesso mi reputo piuttosto naif e a
volte non mi chiedo se qualcosa funzionerà, ma testo se funziona. Poi
ovviamente le migliori guide sono sempre il buon senso e l'esperienza.

Tutto questo per dire che le seguenti linee non hanno la stessa
"capacità informativa", ma esprimono concetti differenti e nessuna delle
due è, a priori, sbagliata.

if not civico.isdigit():
    raise ValueError("Il numero civico deve essere numerico")

assert(civico.isdigit()) "Il numero civico deve essere numerico"

> Il giorno mer, 11/05/2016 alle 11.48 +0100, enrico franchi ha scritto:
> > Oggettivamente non e' troppo sensato fare girare il codice in
> > produzione in modalita' debug, poi fai te. ;)

Enrico è molto stimato in lista e io stesso lo leggo con molto
interesse. E' per questo che quanto dico, lo dico sottovoce: io non
sono totalmente d'accordo. Il mio prof di ingegneria del software disse:
"io faccio girare il software in produzione in modalità debug". Forse
era proprio in previsione per smentire Enrico ;). Nel corso si usava C#
e, non ricordo più a memoria, C# ha qualche costrutto simile al
__debug__ di python, forse delle define come in C ("#ifndef NDEBUG...").

Tutto dipende dal tipo di codice, ma qui non stiamo parlando del
serverino web di Django. Se in produzione non avrò mai una
AssertionError, non vuol dire che sia necessariamente migliore o più
resistende ai bug. Se non avrò una AssertionError subito, avrò comunque
dei grattacapi dopo, perché le assert sono... delle asserzioni molto
forti e, peggio ancora, l'errore si manifesterà in maniere differenti:
un'eccezione di tipo differente (qui allora probabilmente la assert è
mal messa), un'eccezione in pezzo di codice differente o dei dati
sballati.

Ancora peggio è il seguente codice. Il nome mal scelto di un metodo può
portare a delle cose del tipo:

logger = Logger()

def debug(*args):
if __debug__:
logger.debug(*args)

o, che è lo stesso:

if __debug__:
logger.debug(...)

Per quanto belle che siano le traceback e sia bello averle ben
formattate nei log, un'eccezione non mi dice in quale contesto sia
avvenuta, perché ho un intero piuttosto che una stringa o un valore
negativo piuttosto che un intero naturale.

Onestamente mi chiedo quante persone utilizzino l'opzione -O in
produzione. Un piccolo grep in /usr/bin ha confermato le mie
aspettative.

Marco

Ps. All'esame dovevamo presentare un progetto e io glielo portai fatto
in Python allora che una buona parte del programma era su C# :D
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] __debug__ e EAFP

[Pietro Battiston]

Il giorno mer, 11/05/2016 alle 21.29 +0200, m ha scritto:
> * Daniele Tricoli (er...@mornie.org) [160511 21:17]:
> > 
> > Una metafora elettronica che userei è: ho un circuito integrato dal
> > quale mi
> > esco una linea di I/O per fare dei test, ovviamente devo piazzarci
> > a monte un
> > buffer perché sennò avrei prestazioni orribili.
> > Finiti i test, devo andare in produzione, ma prima di mandare tutto
> > ai fab, mi
> > calcolo la power cost del mio integrato e noto (in realtà lo sapevo
> > prima, va)
> > che il buffer lasciato lì, anche se non viene più usato incide nel
> > computo
> > capacitivo e quindi nella dissipazione di potenza.
> > 
> > Quindi *rimuovo per ottimizzare* la dissipazione di potenza il
> > buffer in
> > questione, quando vado in produzione.
> > 
> 
> la cosa che mi piace da matti delle metafore forzate è che sono
> come la marmellata per i facoceri senza denti
> 


Bella, davvero calzante (almeno per chi è al corrente degli annosi
problemi di carie che affliggono i facoceri).

Pietro

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

Re: [Python] __debug__ e EAFP

[Marco Giusti]

On Wed, May 11 2016, Roberto Polli wrote:
> Il 11 maggio 2016 16:31, Pietro Battiston  ha 
> scritto:
> > ... condensare ...
> >
> > if not civico.isdigit():
> > raise ValueError("Il numero civico deve essere numerico")
> >
> > in
> >
> > assert(civico.isdigit()) "Il numero civico deve essere numerico"
> >
> Uso assert se il controllo:
> 
>   - non deve influire sul flusso del programma;
>   - rappresenta condizioni inaspettate e quindi un bug del programma;
>   - come placeholder nelle fasi preliminari - chiarito meglio il
> flusso li sostituisco con eccezioni;
> 
> eg.
> 
> ```
> ret = factorial(n)
> assert ret, "Factorial can't be negative. BUG in the program!"
> print(ret)
> ```

try:
# your code
except AssertionError:
raise AssertionError("BUG in the assertion")
else:
if x < 0:
raise AssertionError("BUG in the assertion")
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python