[Python] 0 in (False,) // 0 == False

Enrico Franchi enrico.franchi a gmail.com
Gio 11 Feb 2010 11:11:51 CET


On Feb 11, 2010, at 9:23 AM, Raffaele Salmaso wrote:

>> Proporlo di cambiarlo
> Scusa, ma in tutto questo giro devo essermelo perso questo passaggio.
> Dove sarebbe?

Scusa, ma con tutti questi snip proprio non riesco a capire a cosa ti riferisci
del mio messaggio. Non ho completamente voglia di grepparmelo per capire
a quale pezzo fai riferimento.

> A me non sembra che nessuno, e ripeto *nessuno*, abbia avuto voglia di
> cambiare il comportamento di python. Ci si chiede solo il perché di una
> scelta che a me francamente True + 1 == 2 fa rizzare i capelli come il
> "4" + 2 == 42 (o potrebbe benissimo anche essere "42", perché no?).

Perche'? Direi che i linguaggi che fanno automaticamente conversione
stringa intero hanno su questa cosa un po' di casi ambigui. Inoltre
la conversione fra stringa e intero e' una conversione vera e propria, che
puo' dare errori e avere ambiguita'. Su questo penso siamo tutti d'accordo.

Da bool ad int invece si avrebbe quella che intermini C e' una *promozione*.
Non ci possono essere errori, non ci possono essere ambiguita'.

Poi, come piu' volte ho ripetuto, e' perfettamente lecito desiderare che mischiare
aritmetica intera e booleana lanci un'eccezione. Che e' l'altro comportamento
sensato oltre a quello attuale. IMHO rimane tuttavia molto meno comodo.

E soprattutto, tanto vale mettersi nell'ordine di idee di abbandonare codice come

if my_list: ...

perche' a quel punto sarebbe difficile sostenere che 0 non deve valutare a falso
quando e' un booleano mentre [] dovrebbe farlo. Se ricordo bene, e' stato detto 
chiaramente che non si vuole nemmeno

if 0:

anche se in questo caso la questione sarebbe piu' relativa a __nonzero__ che
al mischiare booleani e interi.

Il problema e' che in questa cosa si intrecciano due comportamenti diversi. Da
un lato il __nonzero__ che e' alla base delle liste e sequenze vuote, dall'altro avere aritmetica
mista con booleani, di conseguenza conversioni e tutta la combriccola.

Ora io sono disposto a pagare 0 == False per avere aritmetica con booleani. 
Evidentemente tu no. Il che e' lecito, puoi benissimo chiedere le eccezioni.
Ruby, che appunto sceglie che 0 != False fa esattamente questo.

>> 0 + true
TypeError: true can't be coerced into Fixnum
	from (irb):2:in `+'
	from (irb):2

A me pare meno comodo. Amen. :)

Quello che io contesto e' un sistema coerente con aritmetica con i booleani e gli interi
*e* 0 != False.



Maggiori informazioni sulla lista Python