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

Re: [Python] __debug__ e EAFP

[Roberto Polli]

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)
```
___
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 21:17, Daniele Tricoli  ha 
> scritto:
> 
> On Tuesday, May 10, 2016 05:42:05 PM Marco De Paoli wrote:
>> è come se in un circuito uno si prendesse il disturbo di predisporre
>> tutti i fusibili
>> li lascia lì mentre verifica la scheda a banco
>> e poi li toglie tutti (o meglio li mette in corto) una volta che usa
>> la scheda nell'ambito definitivo
>> o sul prodotto industriale
> 
> Premessa, a me la cosa non sorprese, perché il secondo libro che comprai su 
> Python (e che lessi subito dopo il primo) fu la seconda edizione di Python in 
> a Nutshell e questa cosa sull'assert viene detta subito.
> 
> Per quanto riguarda la metafora sui fusibili, a me non convince solo perché, 
> appunto, fin da subito ho letto come funzionavano gli assert.
> 
> 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.
> 

Assert culinaria :

Le assert sono come gli stuzzicadenti negli involtini.
Se non li rimuovi prima di andare in tavola ti si possono
conficcare in gola.


:D

G


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

Re: [Python] __debug__ e EAFP

[m]

* 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

--
 .*.finelli
 /V\
(/ \) --
(   )   Linux: Friends dont let friends use Piccolosoffice
^^-^^ --

Radioactive cats have 18 half-lives.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] __debug__ e EAFP

[Daniele Tricoli]

On Wednesday, May 11, 2016 09:17:07 PM Daniele Tricoli wrote:
> Quindi *rimuovo per ottimizzare* la dissipazione di potenza il buffer in 
> questione, quando vado in produzione.

Usando la punteggiatura correttamente magari viene meglio, eh! Scusate:

Quindi rimuovo, *per ottimizzare la dissipazione di potenza*, il buffer in 
questione quando vado in produzione.

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] __debug__ e EAFP

[Daniele Tricoli]

On Tuesday, May 10, 2016 05:42:05 PM Marco De Paoli wrote:
> è come se in un circuito uno si prendesse il disturbo di predisporre
> tutti i fusibili
> li lascia lì mentre verifica la scheda a banco
> e poi li toglie tutti (o meglio li mette in corto) una volta che usa
> la scheda nell'ambito definitivo
> o sul prodotto industriale

Premessa, a me la cosa non sorprese, perché il secondo libro che comprai su 
Python (e che lessi subito dopo il primo) fu la seconda edizione di Python in 
a Nutshell e questa cosa sull'assert viene detta subito.

Per quanto riguarda la metafora sui fusibili, a me non convince solo perché, 
appunto, fin da subito ho letto come funzionavano gli assert.

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.

:)

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] __debug__ e EAFP

[Roberto Polli]

Il 11 maggio 2016 12:48, enrico franchi  ha scritto:
> 2016-05-10 16:56 GMT+01:00 Pietro Battiston :
>> iniziando .. con assert(__debug__)
> Capisco la battuta, ma se e' non e' una battuta
è una battuta :D

> E detto fra noi... ma veramente vogliamo usare assert come *controllo di
> flusso*?
No :)

@Carlos:
> non va abustao, a mio parere, neppure in devel e test.
Nei test non vedo controindicazioni, fintanto che i messaggi di errore
siano chiari.

Pax,
R:
___
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 11.48 +0100, enrico franchi ha scritto:
> 
> 2016-05-10 16:56 GMT+01:00 Pietro Battiston :
> > Capisco. Beh, d'ora in poi lo utilizzerò solo come programmazione
> > difensiva, ad esempio iniziando ogni mio listato con
> > 
> > assert(__debug__)
> > 
> Capisco la battuta, ma se e' non e' una battuta, spero di non dovere
> mai usare il tuo codice, visto che non potrei farlo funzionare. 

È una battuta!

(la riga è perfettamente equivalente a "pass", quindi il tuo codice
funzionerebbe tranquillamente ;-) )

> Oggettivamente non e' troppo sensato fare girare il codice in
> produzione in modalita' debug, poi fai te. ;)

Sì, d'accordo. Avrei ritenuto enormemente più sensato che "-O" non si
comportasse così... ma alla luce dell'eredità del C capisco.

Per quel che mi riguarda, tenderò ad evitare "assert" d'ora in poi.
Per dire: che sarebbe successo a questo tizio:
http://stackoverflow.com/questions/23778128/python-error-when-calling-f
ourier-transform-code
se quella particolare configurazione di valori gli fosse capitata solo
una volta in produzione? Boh, e chi lo sa, con ogni probabilità il
codice che segue l'assert fallito non è stato testato granché con
parametri non conformi (certamente non dalla suite di testing di numpy,
che gira in modalità debug), magari gli muore fulminato il gatto e non
capisce nemmeno perché finché non fa rigirare in modalità debug con gli
stessi dati di input...


> Poi spesso si fa, figuriamoci. Ma non poterlo fare, potrebbe
> risultare in problemi.
> 
> E detto fra noi... ma veramente vogliamo usare assert come *controllo
> di flusso*?
> 

Guarda, se l'avessi chiesto a me dieci anni fa, nemmeno avrei mai
sospettato che uno potesse utilizzare le eccezioni _in generale_ come
*controllo di flusso*...

> 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.

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

Re: [Python] __debug__ e EAFP

[Luca Bacchi]

Io, prima di scoprire sta storia, scrivevo cose del tipo:

try:
assert len(l) != 0
# using l list
except AssertionError:
raise ValidationError()

Quasi come pattern per implementare semplici validazioni.

Ora so che non va fatto.

Il giorno 11 maggio 2016 13:39, Carlos Catucci 
ha scritto:

> 2016-05-11 12:48 GMT+02:00 enrico franchi :
> > E detto fra noi... ma veramente vogliamo usare assert come *controllo di
> > flusso*?
>
> A me era sembrato di capire che sia un oggetto da usare in svliluppo
> per avere dei conrolli. E non va abustao, a mio parere, neppure in
> devel e test.
> In production non dovebbe arrivare roba che non sia stata testata il
> piu' possibile, e se devo mettere delle assert in produzione ho idea
> che non ho fatto tutti i compiti a casa a modino. O mi sbaglio?
>
> Carlos
> --
> EZLN ... Para Todos Todo ... Nada para nosotros
> ___
> 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] __debug__ e EAFP

[Carlos Catucci]

2016-05-11 12:48 GMT+02:00 enrico franchi :
> E detto fra noi... ma veramente vogliamo usare assert come *controllo di
> flusso*?

A me era sembrato di capire che sia un oggetto da usare in svliluppo
per avere dei conrolli. E non va abustao, a mio parere, neppure in
devel e test.
In production non dovebbe arrivare roba che non sia stata testata il
piu' possibile, e se devo mettere delle assert in produzione ho idea
che non ho fatto tutti i compiti a casa a modino. O mi sbaglio?

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

[enrico franchi]

2016-05-10 16:56 GMT+01:00 Pietro Battiston :

> Capisco. Beh, d'ora in poi lo utilizzerò solo come programmazione
> difensiva, ad esempio iniziando ogni mio listato con
>
> assert(__debug__)
>

Capisco la battuta, ma se e' non e' una battuta, spero di non dovere mai
usare il tuo codice, visto che non potrei farlo funzionare.
Oggettivamente non e' troppo sensato fare girare il codice in produzione in
modalita' debug, poi fai te. ;)
Poi spesso si fa, figuriamoci. Ma non poterlo fare, potrebbe risultare in
problemi.

E detto fra noi... ma veramente vogliamo usare assert come *controllo di
flusso*?

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?



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

Re: [Python] __debug__ e EAFP

[Roberto Polli]

Il 10 maggio 2016 17:42, Marco De Paoli  ha scritto:
> è come se ...  predisporre
> tutti i fusibilie poi li toglie tutti ...
In python forse il paragone ha senso  ;)

In C assert è una cosa. Gli errori gestiti sono un'altra.
assert() usa abort() in caso di fail, quindi niente atexit() & co.

Difficile quindi usarla come "fusibile" ;) E' veramente uno strumento
di debugging.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/assert.html

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

Re: [Python] __debug__ e EAFP

[Pietro Battiston]

Il giorno mar, 10/05/2016 alle 12.08 +0200, Luca Bacchi ha scritto:
> In passato la cosa sconvolse pure me. Mi dissero che "assert" va
> usato solo come forma di programmazione difensiva, non ci devi
> implementare della logica, catturando e gestendo le eccezioni.
> 


Capisco. Beh, d'ora in poi lo utilizzerò solo come programmazione
difensiva, ad esempio iniziando ogni mio listato con

assert(__debug__)

... :-)

Pietro




> Il giorno 10 maggio 2016 12:03, Pietro Battiston
>  ha scritto:
> > Salve a tutti,
> > 
> > ho appena scoperto __debug__ e l'opzione "-O":
> > 
> > https://docs.python.org/2/reference/simple_stmts.html#assert
> > 
> > e non so neanche esattamente come formulare la mia domanda, è più
> > una
> > vaga inquietudine... in un linguaggio in cui è "normale" che una
> > exception venga catturata, come si fa a convivere con l'idea che
> > "ottimizzazione" significhi "tutti gli AssertionError in tutte le
> > possibili librerie che sto usando scompaiono"?!
> > 
> > È considerata una flag criminale e sostanzialmente inutilizzabile?
> > O dovrei invece pensare che il principio EAFP¹ tendenzialmente non
> > si
> > applica agli AssertionError, che invece vengono usati solo
> > veramente
> > per statement che devono essere sempre vere (e non "false ma
> > catched")?
> > (O mi sfugge semplicemente qualcosa?)
> > 
> > Grazie delle illuminazioni,
> > 
> > Pietro
> > 
> > P.S: di ritorno da PyDataLondon - vi suggerisco caldamente, quando
> > lo
> > metteranno online, il video di http://pydata.org/london2016/schedul
> > e/pr
> > esentation/76/
> > 
> > ¹ https://docs.python.org/3/glossary.html#term-eafp
> > ___
> > 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] __debug__ e EAFP

[Marco De Paoli]

Il 10 maggio 2016 17:02, Roberto Polli  ha scritto:
> Il 10 maggio 2016 12:08, Luca Bacchi  ha scritto:
>> "assert" va usato solo come forma di programmazione difensiva,
>
> Il comportamento è ereditato dal C.

non ricordo dove l'ho letta comunque l'immagine mi sembra efficace e
ve la ripropongo
è presa dall'elettronica

è come se in un circuito uno si prendesse il disturbo di predisporre
tutti i fusibili
li lascia lì mentre verifica la scheda a banco
e poi li toglie tutti (o meglio li mette in corto) una volta che usa
la scheda nell'ambito definitivo
o sul prodotto industriale

brr!

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

Re: [Python] __debug__ e EAFP

[Carlos Catucci]

2016-05-10 17:31 GMT+02:00 Marco Santamaria :
> Alex Martelli all'ultimo PyCon di Firenze ha toccato questo punto e il succo
> era che gli assert statement non sono da usare per fare il catch degli
> AssertionError, ma dovrebbero essere usati solo i fase di sviluppo per
> accertarsi che certe condizioni siano verificate. Oppure nei test. Ha
> motivato questo fatto proprio con l'esistenza dell'opzione '-O'.


Infatti

http://www.tutorialspoint.com/python/assertions_in_python.htm

http://www.tutorialspoint.com/python/python_exceptions.htm

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

[Marco Santamaria]

Il 10 maggio 2016 12:03, Pietro Battiston  ha
scritto:
> È considerata una flag criminale e sostanzialmente inutilizzabile?
> O dovrei invece pensare che il principio EAFP¹ tendenzialmente non si
> applica agli AssertionError, che invece vengono usati solo veramente
> per statement che devono essere sempre vere (e non "false ma catched")?

Alex Martelli all'ultimo PyCon di Firenze ha toccato questo punto e il
succo era che gli assert statement non sono da usare per fare il catch
degli AssertionError, ma dovrebbero essere usati solo i fase di sviluppo
per accertarsi che certe condizioni siano verificate. Oppure nei test. Ha
motivato questo fatto proprio con l'esistenza dell'opzione '-O'.

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

Re: [Python] __debug__ e EAFP

[Roberto Polli]

Il 10 maggio 2016 12:08, Luca Bacchi  ha scritto:
> "assert" va usato solo come forma di programmazione difensiva,

Il comportamento è ereditato dal C.

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

Re: [Python] __debug__ e EAFP

[Luca Bacchi]

In passato la cosa sconvolse pure me. Mi dissero che "assert" va usato solo
come forma di programmazione difensiva, non ci devi implementare della
logica, catturando e gestendo le eccezioni.

Il giorno 10 maggio 2016 12:03, Pietro Battiston  ha
scritto:

> Salve a tutti,
>
> ho appena scoperto __debug__ e l'opzione "-O":
>
> https://docs.python.org/2/reference/simple_stmts.html#assert
>
> e non so neanche esattamente come formulare la mia domanda, è più una
> vaga inquietudine... in un linguaggio in cui è "normale" che una
> exception venga catturata, come si fa a convivere con l'idea che
> "ottimizzazione" significhi "tutti gli AssertionError in tutte le
> possibili librerie che sto usando scompaiono"?!
>
> È considerata una flag criminale e sostanzialmente inutilizzabile?
> O dovrei invece pensare che il principio EAFP¹ tendenzialmente non si
> applica agli AssertionError, che invece vengono usati solo veramente
> per statement che devono essere sempre vere (e non "false ma catched")?
> (O mi sfugge semplicemente qualcosa?)
>
> Grazie delle illuminazioni,
>
> Pietro
>
> P.S: di ritorno da PyDataLondon - vi suggerisco caldamente, quando lo
> metteranno online, il video di http://pydata.org/london2016/schedule/pr
> esentation/76/
>
> ¹ https://docs.python.org/3/glossary.html#term-eafp
> ___
> 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] __debug__ e EAFP

[Pietro Battiston]

Salve a tutti,

ho appena scoperto __debug__ e l'opzione "-O":

https://docs.python.org/2/reference/simple_stmts.html#assert

e non so neanche esattamente come formulare la mia domanda, è più una
vaga inquietudine... in un linguaggio in cui è "normale" che una
exception venga catturata, come si fa a convivere con l'idea che
"ottimizzazione" significhi "tutti gli AssertionError in tutte le
possibili librerie che sto usando scompaiono"?!

È considerata una flag criminale e sostanzialmente inutilizzabile?
O dovrei invece pensare che il principio EAFP¹ tendenzialmente non si
applica agli AssertionError, che invece vengono usati solo veramente
per statement che devono essere sempre vere (e non "false ma catched")?
(O mi sfugge semplicemente qualcosa?)

Grazie delle illuminazioni,

Pietro

P.S: di ritorno da PyDataLondon - vi suggerisco caldamente, quando lo
metteranno online, il video di http://pydata.org/london2016/schedule/pr
esentation/76/

¹ https://docs.python.org/3/glossary.html#term-eafp
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python