Il giorno ven, 05/02/2010 alle 13.25 +0100, Daniele Varrazzo ha scritto: > On Fri, 5 Feb 2010 09:57:44 +0100, Lawrence Oluyede <l.oluy...@gmail.com> > wrote: > > 2010/2/5 Pietro Battiston <too...@email.it>: > >> A questo punto, la > >> domanda è, a parità di duck typing, cosa abbia di comodo 0 == False, e > >> l'unica risposta che sono in grado di formulare è "facilità di > >> implementazione". > > > > Non e` quella l'unica risposta, e` molto comodo avere 0, [], {}, () e > > altri contenitori equivalenti a False. > > Si parla di programmazione all'atto pratico, non per forza di > > comodita` dell'implementatore. > > Rispondo a questo msg ma solo perché non saprei a quale appendermi :P > > Non confondiamo 2 cose: una è "essere falso in contesto booleano", per cui > "if X:" può andare in un ramo o nell'altro a seconda del valore di > X.__nonzero__(). Un'altra è il fatto che si possa fare True + False > (l'algebra di boole non prevede operatori numerici tipo la somma).
A me veniva spontaneo identificare il lavoro su campi finiti, e in particolare sugli interi modulo 2^n, ed in particolare sugli interi modulo 2, con un'estensione dell'algebra di boole: per questo immaginavo con "+" lo xor. Ma riconosco che può essere un viaggio mentale mio, e comunque non c'entra molto col nocciolo del discorso. > Un'altra > ancora è il fatto che True + True faccia 2 (che volendo è un dettaglio > implementativo, volendo è una convenzione che viene dal C). Bene: le due > cose da non confondere sono 3. > > 1) Il fatto che ci siano diverse cose "testabili come valori di verità" è > molto comodo in python, più ancora di avere True e False (che infatti sono > abbastanza recenti: python 2.3 iirc). Chiedere che if []: non debba essere > possibile ma debba essere necessario fare "if bool([]):" mi sembra fuori > questione (non così per Raffaele Salmaso, quindi non è un gusto > universale... a me piace che sia così). e qui ci siamo > > 2) Se Python fosse puristicamente puro, forse bool non implementerebbe la > somma. Ora la implementa semplicemente perché eredita da int, ma se anche > non fosse così l'aritmetica mista (1 + true) sarebbe comunque auspicata > (anche nel "mondo perfetto" evocato da Guido) per cui, o implementando > __add__, o implementando __int__ e quindi lasciandosi sommare dopo una > conversione in un intero, in qualche modo si sarebbe fatto. È come dire "è > sensato che esista una funzione definita dai bool agli int". Se non > esistesse, la gente se la scriverebbe perché farebbe comodo, quindi tanto > vale uniformare il valore di di int(B) per ogni B booleano. ci siamo > > 3) Deciso che deve fare un numero, nel senso - e solo nel senso - che deve _comportarsi come un numero_ dal punto di vista del duck typing > quanto devono valere int(True) e > int(False)? Python usa la convenzione C, dove non ci sono bool, solo > numeri, e 0 è il valore falso (quello che fa prendere il ramo else ad un > if) e 1 è il valore vero (nel senso che !0 = 1, e !!10 = 1, non che esista > una keyword "true"). È un numero sensato perché non é dipendente > dall'implementazione (mentre il risultato del not booleano "~0" lo è) e > perché qualunque rappresentazione numerica plausibile (interi, floating > point, virgola fissa, numeri complessi...) penso si possa assumere conterrà > 0 e 1 :) ci siamo > > Credo che il thread sia partito facendosi domande sul punto 2). Credo di no: nel punto 2) ti chiedi se la somma e il casting automatico a int dei booleani abbia senso, e io come te credo di sì. Il punto è solo se Bool deve essere una subclass di int. E ribadisco che a me sembra solo una facilità di implementazione. > False == 0 > deriva dal fatto che per Python si sia scelto di avere aritmetica mista (il > fatto che bool subclassi int è un dettaglio di come si sia ottenuta). È una > scelta che si sarebbe potuto non fare, sono abbastanza sicuro che linguaggi > BDSM tipo Pascal non l'adottino, ma rientra abbastanza nello "stile > Python": è utile e, una volta deciso quanto fa int(B), non è ambigua (come > invece lo è int + str: in tanti linguaggi 10 + "20" ha un risultato e se > sia 30 o "1020" sta al gusto del suo progettista). > Ripeto: in un mondo ideale, io asserterei "True + 1 == 2" _e_ "True != 1" senza timore... Vedila così: supponi che in Python i booleano non siano interi, e supponi che esca uno e dica "__add__ tra bool e numerici non è implementato: implementiamolo come __add__ tra numerici dopo avere trasformato False in 0 e True in 1, può fare comodo". Allora a mio avviso avremmo il mondo ideale. Pietro _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python