Re: [Python] 0 in (False,) // 0 == False
On Feb 11, 2010, at 12:24 AM, Pietro Battiston wrote: Quando si parla di vantaggi concreti, preferisco farlo davanti a dati concreti. Che sarebbero? Ovviamente non intendevo che l'aritmetica possa esistere senza uguaglianza, ma che il simbolo = può essere definito ben a monte dell'aritmetica, in maniera vagamente simmetrica a quel che succede appunto nel Python. Probabilmente diamo dunque un differente significato al concetto di non avere niente a che fare. Comunque una volta che siamo in accordo, tutto bene. Poi ovviamente si, sono d'accordo che un uguaglianza possa stare a monte dell'aritmetica (uguaglianza semantica, intendo, l'uguaglianza sintattica e' una bestia ancora diversa). Anche l'uguaglianza di python e', ovviamente potenzialmente semantica. Sebbene il default di object sia la versione ad oggetti dell'uguaglianza sintattica, ovvero la completa identita', di fatto poi == e' ridefinito per vaste classi di oggetti. Suppongo che su sta roba siamo tutti d'accordo e non sia necessario soffermarci oltre. Se le tue intuizioni informatiche sono azzeccate quanto quelle personali, non mi stupisce la confusione che fai parlandone. Ottimo. Allora ci hai lavorato anche tu e dovresti essere piuttosto consapevole del fatto che definire formalmente un metodo di un oggetto di un linguaggio completamente dinamico sia un lavoraccio, visto che hai la *semantica* che dipende dall'esecuzione, visto che quale codice venga chiamato da una data chiamata di funzione (o anche solo da un accesso a membro) e' potenzialmente non noto a compile time. Anche immaginando un == scritto staticamente c' da fare un discreto lavoro per formalizzare il tutto. E non credo che la cosa ci porti da nessuna parte, ma se vuoi iniziare ti seguo e vediamo di metterla in piedi. (N.B: non risponderò in maniera polemica a parti della tua email che non siano gratuitamente polemiche. Anzi, facciamo che alle altre parti gratuitamente polemiche non rispondo proprio.) Ottimo. A me risultava che la forte polemica fosse partita nel tuo messaggio, posso ovviamente sbagliare. Se abbassiamo i toni sono completamente d'accordo. Se trovi parti del mio nuovo messaggio che ritieni inutilmente polemiche, ti chiedo scusa in anticipo e segnalamele. La tua teoria secondo cui tutto deve necessariamente essere così com'è si poteva (almeno, mi ero figurato che si potesse) motivare dal punto di vista dell'eleganza matematica _o_ dell'attinenza alla mentalità pythonesca: se tu dici che la matematica non c'entra niente, tirala pure via, altrimenti vai fino in fondo e facciamo le cose bene, la precisione non è mai sgradevole. Guarda, io sono una persona abbastanza pedante. Sono molto formale, a volte pure troppo. Il motivo per cui vorrei lasciare perdere l'eleganza matematica e' che spesso nel mondo pragmatico dei linguaggi di programmazione viene sacrificata in molti punti e modi ben peggiori di questo. Il che vuole dire che appellarsi troppo all'intuizione matematica non di rado porta fuori strada. Di fatto sono pochissimi i linguaggi che non soffrono di questo problema, e a volte sono parecchio scomodi proprio per questa ragione. Io poi non sostengo che tutto debba essere come e'. Non ho parlato di tutto. Ti ho anche indicato un punto che trovo sgradevole (e che fortunatamente hanno fixato in Python 3). Posso aggiungere che mi piacerebbe che Python potesse essere tail recursive (anche se so perche' non PUO' esserlo). Etc etc etc. Riguardo al problema specifico, abbiamo sempre sta cosa qua. O sacrifichi l'aritmetica mista (e lanci eccezioni), oppure tieni le cose come sono, con False che si comporta come 0. Se ho capito bene, tu vorresti 0 != da False *ma* avendo aritmetica mista. E questo IMHO non porta da nessuna parte. Stai scherzando?! Questo punto è stato chiarito 6 mail fa. _Evidentemente_ if 0: print ciao - ... if []: print ciao - ... No, non sto scherzando. Continui a chiedermelo. Se stessi scherzando proverei con delle barzellette. Se scrivo su un gruppo tecnico, è probabile che non stia scherzando. Probabilmente non ti piace il Python idiomatico. Utilizzare cose come if len([]) == 0: sono considerate *cattiva* pratica. Proporre di abbandonare la pratica considerata buona di if []: IMHO non è particolarmente sensato. Veramente ho concluso che _potrebbero_ benissimo esserlo, e che io lo troverei più intuitivo - a prescindere dall'abitudine, ovviamente. Potrebbero essere qualunque cosa. La praticità della cosa rimarrebbe discutibile, tuttavia. Non ne vedo affatto la ragione. Se dopo tutte queste mail ti sfugge ancora la semantica che ho in mente, te la rispiego: il comportamento dei bool rimane _ovunque_ quello che è, tranne che 0 != False (e ovviamente ottieni risultati diversi se vai a vedere l'ereditarietà). Mi sfugge perche' non mi sembrava scritto nero su bianco. Anzi, mi sembra che altaleni fra NON ammettere l'aritmetica mista e ammetterla ma con 0 != da False. Come si
Re: [Python] 0 in (False,) // 0 == False
[snip su tutto che francamente è quasi polemica pura] Enrico Franchi wrote: Proporlo di cambiarlo Scusa, ma in tutto questo giro devo essermelo perso questo passaggio. Dove sarebbe? andando a toccare dei punti che a Guido piaccioni, E amen, fin qui penso sia assodato che sia qualcosa che a Guido piaccia. è *evidentemente* improbabile. 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?). -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
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. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
On Feb 6, 2010, at 11:46 PM, Pietro Battiston wrote: Il punto che forse non è chiaro è cosa sia l'aritmetica. Sarebbe da capire a chi non è chiaro cosa sia. Sono abbastanza sicuro di non essere io quello con dubbi o lacune. Qui si sta parlando di aritmetica mista fra interi e booleani. Che a te da fastidio, a me e a Guido no. Quello che io ho scritto è semplicemente che *se* vuoi aritmetica che coinvolga anche i booleani di fatto la cosa più naturale è che False sia equivalente a 0 e True ad 1, al di la del fatto che bool is-a int per l'implementazione corrente. Se poi bandisci tale aritmetica hai semplicemente un linguaggio decisamente meno comodo senza essenzialmente nessun vantaggio concreto. Sia dal punto di vista matematico che da quello del Python, == è qualcosa che non ha _niente_ a che fare con l'aritmetica: dal punto di vista logico-matematico perché l'eguaglianza non è (necessariamente) un operatore, dal punto di vista di come ragiona il Python perché == può confrontare due oggetti qualsiasi, non solo numerici. Diventa l'uguaglianza tra numeri... esattamente quando gli argomenti sono due numeri. 1. Da un punto di vista matematico il predicato = (che da pythonisti chiamiamo ==) ha *tantissimo* a che fare con l'aritmetica stessa. Non so se hai fatto un minimo di fondamenti, ma fra gli assiomi di peano ci sono precisamente quelli che riguardano =, senza non fondi l'aritmetica sulla set theory. Puoi fondarla sulla logica combinatoria, ma ovviamente stiamo spostandoci alquanto. 2. Dal punto di vista matematico un operatore come il == è una bestiaccia. Immagino tu non abbia lavorato più di tanto (suppongo nulla) sulla semantica formale dei linguaggi di programmazione. Formalizzare un linguaggio ad oggetti è abbastanza un bagno di sangue (fidati, è un bagno di sangue anche avere un linguaggetto come C). Formalizzare qualcosa come Python è essenzialmente un suicidio. La semantica denotazionale è essenzialmente inadatta. Io avevo lavorato parecchio con structured operational semantics, che funzionerebbe anche decentemente... ma il dinamismo di Python sarebbe una iattura. Quindi, tiriamo fuori la matematica dal discorso. O le cose si fanno bene, e ti garantisco che quando si va sul formale divento *davvero* sgradevolmente pignolo, oppure la tiriamo indietro. Ma fino in fondo. Quindi rimaniamo al problema fondamentale: stiamo cercando di avere booleani che si comportano come gli interi. Se no, devi proibire le commistioni. Ed essenzialmente hai un altro linguaggio, che non è Python, che è più scomodo di Python e che, per coerenza, deve andare contro molte convenzioni ed idiomi pythonici. Già... se ci troviamo if 0: print ciao - ciao mi aspetto anche if []: print ciao - ciao e per risolvere la cosa... if bool([])? Fa schifo. Allora tanto vale prendersi if len([]) == 0: che è un tipico idioma anti-pythonico, sconsigliato a tutti i niubbi. Stai scherzando?! Questo punto è stato chiarito 5 mail fa. _Evidentemente_ bool(0) == False. Nope. Tu parti dal presupposto che i bool e gli int debbano essere tipi distinti. E guarda caso concludi che debbano essere tipi distinti. Il che porta un po' a quello che veramente è stato detto alcune mail fa. Ovvero che di per se puoi benissimo tirare un'eccezione ogni volta che mischi interi e booleani. Ma *non* è quello che vuole Guido. Per inciso continuo a non vedere il vantaggio di farlo in Python. E a quel punto mi aspetto anche che l'inferno si scateni quando mischio float e interi. Comunque davvero, la cosa più naturale è vedere True e False come numeri a 1-bit. Non dubito che per te possa essere (ormai?) naturale... Ormai? Non so. Non vedo perchè un numero di un bit non debba essere un numero. Ah, tu dici che non è un numero. Ok. Un numero di due bit è un numero? No? Uno di 31? No? uno di 32? Si. Ah, ok. Non ci formalizziamo perchè 0 == 0L, ma ci da fastidio False. ... ma renditi conto che questo è un argomento che non c'entra niente. Come non centra niente? 0L è lo 0 dei long, 0 degli int, False dei bool. Caso che mai non ti fosse sfuggito, long e int sono tipi *diversi* in Python. Eppure non ti stupisci che lo 0 dei long sia diverso dallo 0 degli interi. Per non parlare dello 0 dei float e quello degli interi. Tutti i tipi numerici hanno somma, sottrazione, moltiplicazione, divisione (questa, con qualche distinguo), che definiscono su di essi delle immersioni che sono più che canoniche, sono _ovvie_: i naturali (chiusi solo per la somma) sono degli interi (chiusi per somma, sottrazione, prodotto), che sono dei razionali (OK, questi l'informatica per quanto ne so ce li risparmia), che sono dei reali (chiusi per tutte le operazioni - tralasciando la rappresentazione approssimata), che volendo sono dei complessi. Ti mancano un sacco di pezzi, mi dispiace. Di fatto ti aspetti erroneamente che i tipi numerici in macchina si comportino come quelli della matematica. In primo luogo l'informatica non ci
Re: [Python] 0 in (False,) // 0 == False
On 02/10/2010 10:48 PM, Enrico Franchi wrote: Una volta ammessa sta somma fra interi che da un long, Non ripeterlo troppe volte, perche' P3K ha giustamente unificato gli interi. -- This e-mail (and any attachment(s)) is strictly confidential and for use only by intended recipient(s). Any use, distribution, reproduction or disclosure by any other person is strictly prohibited. The content of this e-mail does not constitute a commitment by the Company except where provided for in a written agreement between this e-mail addressee and the Company. If you are not an intended recipient(s), please notify the sender promptly and destroy this message and its attachments without reading or saving it in any manner. Any non authorized use of the content of this message constitutes a violation of the obligation to abstain from learning of the correspondence among other subjects, except for more serious offence, and exposes the person responsible to the relevant consequences. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
On 02/10/2010 10:48 PM, Enrico Franchi wrote: Altra novita' di Python 3: Questo si che fa un po' cacare. Certo un pervertito che va a rinominare True si merita tutto il male che può capitargli. E siccome i Pythonisti sono tutti adulti e vaccinati, si fa conto che quella cosa lassù non venga mai fatta e che tanto se uno vuole fottere il sistema ci sono anche metodi più creativi. Python 3.1.1 (r311:74480, Feb 1 2010, 17:06:28) [GCC 4.4.1] on linux2 Type help, copyright, credits or license for more information. True=False File stdin, line 1 SyntaxError: assignment to keyword ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
On Feb 10, 2010, at 11:19 PM, Marco Mariani wrote: Non ripeterlo troppe volte, perche' P3K ha giustamente unificato gli interi. Giustamente si! Perchè la faccenda era solo un dettaglio implementativo. E sono molto contento. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
Il giorno mer, 10/02/2010 alle 22.48 +0100, Enrico Franchi ha scritto: On Feb 6, 2010, at 11:46 PM, Pietro Battiston wrote: Il punto che forse non è chiaro è cosa sia l'aritmetica. Sarebbe da capire a chi non è chiaro cosa sia. Sono abbastanza sicuro di non essere io quello con dubbi o lacune. Qui si sta parlando di aritmetica mista fra interi e booleani. Che a te da fastidio, a me e a Guido no. Quello che io ho scritto è semplicemente che *se* vuoi aritmetica che coinvolga anche i booleani di fatto la cosa più naturale è che False sia equivalente a 0 e True ad 1, al di la del fatto che bool is-a int per l'implementazione corrente. Se poi bandisci tale aritmetica hai semplicemente un linguaggio decisamente meno comodo senza essenzialmente nessun vantaggio concreto. Quando si parla di vantaggi concreti, preferisco farlo davanti a dati concreti. Sia dal punto di vista matematico che da quello del Python, == è qualcosa che non ha _niente_ a che fare con l'aritmetica: dal punto di vista logico-matematico perché l'eguaglianza non è (necessariamente) un operatore, dal punto di vista di come ragiona il Python perché == può confrontare due oggetti qualsiasi, non solo numerici. Diventa l'uguaglianza tra numeri... esattamente quando gli argomenti sono due numeri. 1. Da un punto di vista matematico il predicato = (che da pythonisti chiamiamo ==) ha *tantissimo* a che fare con l'aritmetica stessa. Non so se hai fatto un minimo di fondamenti, ma fra gli assiomi di peano ci sono precisamente quelli che riguardano =, senza non fondi l'aritmetica sulla set theory. Puoi fondarla sulla logica combinatoria, ma ovviamente stiamo spostandoci alquanto. Uhm, fammici pensare... sì, ho fatto un minimo di fondamenti. Ovviamente non intendevo che l'aritmetica possa esistere senza uguaglianza, ma che il simbolo = può essere definito ben a monte dell'aritmetica, in maniera vagamente simmetrica a quel che succede appunto nel Python. 2. Dal punto di vista matematico un operatore come il == è una bestiaccia. Immagino tu non abbia lavorato più di tanto (suppongo nulla) sulla semantica formale dei linguaggi di programmazione. Se le tue intuizioni informatiche sono azzeccate quanto quelle personali, non mi stupisce la confusione che fai parlandone. (N.B: non risponderò in maniera polemica a parti della tua email che non siano gratuitamente polemiche. Anzi, facciamo che alle altre parti gratuitamente polemiche non rispondo proprio.) Formalizzare un linguaggio ad oggetti è abbastanza un bagno di sangue (fidati, è un bagno di sangue anche avere un linguaggetto come C). Formalizzare qualcosa come Python è essenzialmente un suicidio. La semantica denotazionale è essenzialmente inadatta. Io avevo lavorato parecchio con structured operational semantics, che funzionerebbe anche decentemente... ma il dinamismo di Python sarebbe una iattura. Quindi, tiriamo fuori la matematica dal discorso. O le cose si fanno bene, e ti garantisco che quando si va sul formale divento *davvero* sgradevolmente pignolo, oppure la tiriamo indietro. Ma fino in fondo. La tua teoria secondo cui tutto deve necessariamente essere così com'è si poteva (almeno, mi ero figurato che si potesse) motivare dal punto di vista dell'eleganza matematica _o_ dell'attinenza alla mentalità pythonesca: se tu dici che la matematica non c'entra niente, tirala pure via, altrimenti vai fino in fondo e facciamo le cose bene, la precisione non è mai sgradevole. Quindi rimaniamo al problema fondamentale: stiamo cercando di avere booleani che si comportano come gli interi. Se no, devi proibire le commistioni. Ed essenzialmente hai un altro linguaggio, che non è Python, che è più scomodo di Python e che, per coerenza, deve andare contro molte convenzioni ed idiomi pythonici. Già... se ci troviamo if 0: print ciao - ciao mi aspetto anche if []: print ciao - ciao e per risolvere la cosa... if bool([])? Fa schifo. Allora tanto vale prendersi if len([]) == 0: che è un tipico idioma anti-pythonico, sconsigliato a tutti i niubbi. Stai scherzando?! Questo punto è stato chiarito 6 mail fa. _Evidentemente_ if 0: print ciao - ... if []: print ciao - ... Stai scherzando?! Questo punto è stato chiarito 5 mail fa. _Evidentemente_ bool(0) == False. Nope. Tu parti dal presupposto che i bool e gli int debbano essere tipi distinti. E guarda caso concludi che debbano essere tipi distinti. Veramente ho concluso che _potrebbero_ benissimo esserlo, e che io lo troverei più intuitivo - a prescindere dall'abitudine, ovviamente. Il che porta un po' a quello che veramente è stato detto alcune mail fa. Ovvero che di per se puoi benissimo tirare un'eccezione ogni volta che mischi interi e booleani. Non ne vedo affatto la ragione. Se dopo tutte queste mail ti sfugge ancora la semantica che ho in mente, te la rispiego: il comportamento dei bool rimane _ovunque_ quello che è, tranne che 0
Re: [Python] 0 in (False,) // 0 == False
On Feb 11, 2010, at 3:12 AM, Alessandro Dentella wrote: Era un ottimo proposito... intendo non tediare il gruppo, invece ci hai rifilato un polpettone di informazioni la cui faziosità era palese dall'inizio (sarebbe offensivo pensare che invece tu non te ne renda conto), Addirittura faziosità. ben condito con allusioni all'ignoranza degli interlocutori (l'attacco è la miglior difesa) Ovviamente è sfuggito che il primo ad iniziare con tali allusioni è stato un altro. ed a supposta affinità con bdfl (Guido dice che sarebbe meglio una cosa, tu ritieni che è indispensabile l'opposto). Nessuna affinità. Semplicemente Python, a differenza di tanti altri linguaggi nasce dal progetto coerente di *una* mente. In tanti contribuiscono e propongono, ma l'ultima parola sta precisamente a Guido. Il risultato è il python odierno. Può piacere o non piacere. Ma questo è. Proporlo di cambiarlo andando a toccare dei punti che a Guido piaccioni, è *evidentemente* improbabile. E *forse* nemmeno tanto sensato. A volte mi dico che sei uno psicologo e che usi il gruppo per studiare chi reagisce, un po' come Galvani con le rane. Chissà se scrivi di noi nei gruppi di psicologia... No, mi dispiace. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
On 02/06/2010 11:03 PM, Enrico Franchi wrote: Non ci formalizziamo perchè 0 == 0L, ma ci da fastidio False. Ma parlate per voi... A me da' fastidio 'undefined', ritengo che sia la prova ultima che Dio non esiste :-p -- This e-mail (and any attachment(s)) is strictly confidential and for use only by intended recipient(s). Any use, distribution, reproduction or disclosure by any other person is strictly prohibited. The content of this e-mail does not constitute a commitment by the Company except where provided for in a written agreement between this e-mail addressee and the Company. If you are not an intended recipient(s), please notify the sender promptly and destroy this message and its attachments without reading or saving it in any manner. Any non authorized use of the content of this message constitutes a violation of the obligation to abstain from learning of the correspondence among other subjects, except for more serious offence, and exposes the person responsible to the relevant consequences. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
Il giorno sab, 06/02/2010 alle 23.03 +0100, Enrico Franchi ha scritto: On Feb 5, 2010, at 8:24 PM, Alessandro Dentella wrote: in attesa che Enrico mantenga la promessa e mostri gli assurdi completi che quanto scritto sopra comporterebbe. Essenzialmente ha spiegato tutto già Daniele. Gli assurdi saltano fuori dalla posizione: In an ideal world, bool might be better implemented as a separate integer type that knows how to perform mixed-mode arithmetic. Ovvero noi *vogliamo* mixed mode arithmetic. Tolto questo assunto, è ovviamente completamente possibile gestire in modo consistente le operazioni fra interi e booleani lanciando eccezioni. Il punto è che IMHO l'aritmetica che coinvolge i booleani è estremamente comoda. Evidentemente anche secondo Guido. Quindi partiamo dal volere che un booleano possa stare in ogni posto dove possa stare un intero. Il punto che forse non è chiaro è cosa sia l'aritmetica. Sia dal punto di vista matematico che da quello del Python, == è qualcosa che non ha _niente_ a che fare con l'aritmetica: dal punto di vista logico-matematico perché l'eguaglianza non è (necessariamente) un operatore, dal punto di vista di come ragiona il Python perché == può confrontare due oggetti qualsiasi, non solo numerici. Diventa l'uguaglianza tra numeri... esattamente quando gli argomenti sono due numeri. Consideriamo anche ragionevole che: 1) a + (-a) == a - a == 0 2) m - n 0 == m n Dove a, m e n sono interi, certo. Ma soprattutto chiediamoci cosa *dovrebbe* fare False + True o una cosa come True * 5 è completamente chiaro che il tutto è relativamente arbitrario (in particolare True == 5 invece che True == 1 non darebbe problemi). Ma prendere False != da 0 ci porrebbe nell'imbarazzante condizione di avere if 0: print foo che stampa foo. Stai scherzando?! Questo punto è stato chiarito 5 mail fa. _Evidentemente_ bool(0) == False. Comunque davvero, la cosa più naturale è vedere True e False come numeri a 1-bit. Non dubito che per te possa essere (ormai?) naturale... Non ci formalizziamo perchè 0 == 0L, ma ci da fastidio False. ... ma renditi conto che questo è un argomento che non c'entra niente. Tutti i tipi numerici hanno somma, sottrazione, moltiplicazione, divisione (questa, con qualche distinguo), che definiscono su di essi delle immersioni che sono più che canoniche, sono _ovvie_: i naturali (chiusi solo per la somma) sono degli interi (chiusi per somma, sottrazione, prodotto), che sono dei razionali (OK, questi l'informatica per quanto ne so ce li risparmia), che sono dei reali (chiusi per tutte le operazioni - tralasciando la rappresentazione approssimata), che volendo sono dei complessi. In tutto ciò i booleani, che sono nati come logica a due valori in cui le due operazioni standard erano or (l'equivalente intero è max, non una delle operazioni aritmetiche) e and (min), sono un caso a parte. Ma non c'è solo problema storico: c'è che seppure l'addizione (così come la sottrazione) assomiglia ad un'operazione logica, lo xor, purtroppo l'insieme dei booleani _non è chiuso_ rispetto ad essa (dato che anche assumendo che i booleani siano numeri, True + True non sarebbe un booleano): ovvero non si comporta affatto come lo xor. Quindi _comunque_ quando parliamo di addizione di booleani è piuttosto ipocrita spacciarla per un'operazione nativa: è, come tutti hanno ammesso, una comodissima eredità del C. D'altronde, vedila in un altro modo: se per te è perfettamente naturale che i booleani siano semplicemente (un piccolo sottoinsieme degli) interi, e ti sembra quindi naturale che siano _identici_ in tutto e per tutto rispettivamente a 0 e 1, non ti sembrerebbe naturale anche che In [1]: isinstance(1,bool) Out[1]: True ?! La scomoda verità è che se volessimo una cosa pulita con False != 0, il modo giusto sarebbe che, come in C, False e True fossero semplicemente _definiti_ individualmente come 0 e 1. Solo che il tipo bool ci fa comodo... mentre la riga di codice che ho scritto sopra è assolutamente inutile. Ciò detto, ho già scritto che in fondo me ne frega assai: è evidente che, posto che Guido si è già espresso, tutto il thread è puramente teorico. Se vogliamo fare aritmetica mista (che è l'assunto), ci troviamo a dovere dare convenzionalmente un valore a True e False. E ovviamente tutte le scelte possibili sarebbero peggiori e meno intuitive di questa. Se vuoi ribattere, fallo con precisione su uno dei punti esposti finora in una delle tante mail, che sennò non si finisce più. ciao Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
Il 04 febbraio 2010 18.38, Enrico Franchi enrico.fran...@gmail.com ha scritto: Guarda, è roba di algebra elementare. Se vuoi *veramente* che te la faccia, te la faccio pure. Roba da cinque minuti. Per me e per te, basta chiedere. Se posso evito di tediare il gruppo con svariate righe di banalità matematiche. Anch'io son curioso :) (Per dovere di cronaca, a me piace 0==False). Ciao, -- Marco Dalla Stella web: http://thediracsea.org twitter: http://twitter.com/kra1iz3c ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
On Feb 4, 2010, at 7:11 PM, Pietro Battiston wrote: Beh, ormai io sono curioso... Ok. Appena trovo un attimo per ricercare un esempio significativo. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
Marco Dalla Stella wrote: Ok, si vede che vieni da Java, io personalmente vengo da Perl, per cui... :) col ca**o, né java né perl c e c++, prego :D ;) e li di porcate ne ho anche fatte, altro che int === boolean :D -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
On Fri, Feb 5, 2010 at 9:41 AM, Raffaele Salmaso raffaele.salm...@gmail.com wrote: e li di porcate ne ho anche fatte, altro che int === boolean :D Beh in Python non e` che puoi fare molte porcate eh, in genere il trucchettino di boolean equivalente ad intero e` usato per la cortocircuitazione logica o la selezione condizionale. Niente di galattico. -- Lawrence Oluyede [eng] http://oluyede.org - http://twitter.com/lawrenceoluyede [ita] http://www.neropercaso.it [flickr] http://www.flickr.com/photos/rhymes ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
Marco Dalla Stella wrote: Ma perché? A che pro? chiarezza dell'intento, direi essere espliciti, e non renderlo implicito o magico o chissàche -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
Lawrence Oluyede wrote: Beh in Python non e` che puoi fare molte porcate eh, veramente pensavo a giochi con la memoria e altro, che ti viene semplice in c/c++ e giusto un pelo meno con python in genere il trucchettino di boolean equivalente ad intero e` usato per la cortocircuitazione logica o la selezione condizionale. Niente di galattico. come dissi: comodo, non lo nego però preferirei essere esplicito nell'intento -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
Il giorno ven, 05/02/2010 alle 09.49 +0100, Raffaele Salmaso ha scritto: Lawrence Oluyede wrote: Beh in Python non e` che puoi fare molte porcate eh, veramente pensavo a giochi con la memoria e altro, che ti viene semplice in c/c++ e giusto un pelo meno con python in genere il trucchettino di boolean equivalente ad intero e` usato per la cortocircuitazione logica o la selezione condizionale. Niente di galattico. come dissi: comodo, non lo nego però preferirei essere esplicito nell'intento Anch'io trovo Haskell un linguaggio molto elegante, a modo suo. Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
2010/2/5 Raffaele Salmaso raffaele.salm...@gmail.com: Marco Dalla Stella wrote: Ma perché? A che pro? chiarezza dell'intento, direi essere espliciti, e non renderlo implicito o magico o chissàche Il bello del dynamic typing... se no passa ad un linguaggio statically typed... -- Marco Dalla Stella web: http://thediracsea.org twitter: http://twitter.com/kra1iz3c ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
Lawrence Oluyede wrote:
Vero, ma non ha senso essere espliciti dall'altra parte.
Fare una cosa come:
(a, b)[c==0]
e` sicuramente una porcata (soprattutto ora che c'e` l'operatore
ternario), ma non credo che
sinceramente, non mi piace come è implementato l'operatore ternario,
anche se dubito che in python si possa fare di meglio
invece l'idioma di cui sopra non mi dispiace per niente, anche se non è
detto che lo userei paro paro così (di solito gli assegno un nome e poi
lo seleziono)
if something:
sia piu` oscuro di:
if bool(something):
più che altro, non stavo in effetti pensando solo ad int ma anche a [] e
{} che sono == False
Avrei piu` paura di cose come 'a' + 3 che altri linguaggi supportano
io no, non li uso e li evito il più possibile ;)
Comunque non ha molta importanza, separare bool da int ora romperebe
il 99% del codice esistente :P
direi che se doveva essere fatto, era da fare in python3.0
oramai è solo un chiacchierare che voglia di riscrivere tutto non ne ho
eh :D
--
()_() | That said, I didn't actually _test_ my patch. | +
(o.o) | That's what users are for! | +---+
'm m' | (Linus Torvalds) | O |
(___) | raffaele dot salmaso at gmail dot com |
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
2010/2/5 Raffaele Salmaso raffaele.salm...@gmail.com: io no, non li uso e li evito il più possibile ;) Non hai mai usato JavaScript allora :-) direi che se doveva essere fatto, era da fare in python3.0 Boh, probabile oramai è solo un chiacchierare che voglia di riscrivere tutto non ne ho eh :D :-) -- Lawrence Oluyede [eng] http://oluyede.org - http://twitter.com/lawrenceoluyede [ita] http://www.neropercaso.it [flickr] http://www.flickr.com/photos/rhymes ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
Lawrence Oluyede wrote: 2010/2/5 Raffaele Salmaso raffaele.salm...@gmail.com: io no, non li uso e li evito il più possibile ;) Non hai mai usato JavaScript allora :-) ho detto possibile, non che non ci riesco (poi invero non è molto malvagio, a parte circa il 70% - conservativo - di regole da riscrivere... per fortuna cerco di usare solo chiamate a jquery e basta :D) -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
(Per dovere di cronaca, a me piace 0==False).
A me sinceramente no.
Un booleano è un booleano.
Un numero è un numero.
chiarezza dell'intento, direi
essere espliciti, e non renderlo implicito o magico o chissàche
if not(return_code):
if (return_code == 0):
if not(bool(return_code)):
La condizione è una comparazione fra due variabili di tipo diverso,
ma l'intero rimane intero e il booleano rimane booleano.
return_code = 0
if not(return_code):
... print type(return_code)
...
type 'int'
Questo permette di essere molto semplici nel costruire le condizioni
1)
a = list('abcdefghilmnopqrstuvz')
while a:
print a.pop()
2) while len(a)0:
3) while bool(len(a)):
Lo leggo così: Finchè la lista 'a' è ancora significativa:
---
Wyrmskull
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
Il giorno ven, 05/02/2010 alle 10.07 +0100, Lawrence Oluyede ha scritto: 2010/2/5 Pietro Battiston too...@email.it: In [5]: [] == False Out[5]: False In [2]: if []: print aa ...: ovviamente l'osservazione che vorrei scrivere è quella che nel frattempo ha scritto Sandro... Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
Lawrence Oluyede wrote: A me JS piace :-) prova lua[1] allora: js done right ;) peccato non vada in un browser... poi anche a me non dispiace, solo che ha regole in alcuni casi un po' diciamo sui generis, indi cerco di usarlo il meno spinto possibile. [1] http://www.lua.org -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
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). 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ì).
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.
3) Deciso che deve fare un numero, 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 :)
Credo che il thread sia partito facendosi domande sul punto 2). 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).
--
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] 0 in (False,) // 0 == False
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
Re: [Python] 0 in (False,) // 0 == False
On Fri, 05 Feb 2010 14:41:00 +0100, Pietro Battiston too...@email.it
wrote:
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.
La domanda originale, come riportata anche nel titolo è: perchè 0 in
(False,) fa True? Questa è una diretta conseguenza di tuple.__contains__,
che porta alla domanda perché '0 == False' fa True?. Questo è perché si è
desiderata l'aritmetica mista. Alessandro fa un passo ulteriore e incolpa
questa proprietà al fatto che bool sublassi int. Ma il subclassing è solo
il modo (economico) in cui si è deciso di implementare la proprietà: si
sarebbe potuto avere aritmetica mista senza subclass, ed entrambe le
domande nel titolo del post sarebbero ancora... domandabili.
Ripeto: in un mondo ideale, io asserterei True + 1 == 2 _e_ True !=
1 senza timore...
A me un pò di timore fa... Se le due proprietà di sopra fossero vere:
True + 1 == 2 = True + 1 - 1 == 2 - 1 = True == 1
Quindi non puoi avere anche True != 1, a meno di non rompere il
funzionamento degli interi.
--
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] 0 in (False,) // 0 == False
Il giorno ven, 05/02/2010 alle 14.58 +0100, Daniele Varrazzo ha scritto:
On Fri, 05 Feb 2010 14:41:00 +0100, Pietro Battiston too...@email.it
wrote:
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.
La domanda originale, come riportata anche nel titolo è: perchè 0 in
(False,) fa True? Questa è una diretta conseguenza di tuple.__contains__,
che porta alla domanda perché '0 == False' fa True?. Questo è perché si è
desiderata l'aritmetica mista.
no, vedi sotto
Alessandro fa un passo ulteriore e incolpa
questa proprietà al fatto che bool sublassi int. Ma il subclassing è solo
il modo (economico) in cui si è deciso di implementare la proprietà: si
sarebbe potuto avere aritmetica mista senza subclass, ed entrambe le
domande nel titolo del post sarebbero ancora... domandabili.
Ripeto: in un mondo ideale, io asserterei True + 1 == 2 _e_ True !=
1 senza timore...
A me un pò di timore fa... Se le due proprietà di sopra fossero vere:
True + 1 == 2 = True + 1 - 1 == 2 - 1 = True == 1
Quindi non puoi avere anche True != 1, a meno di non rompere il
funzionamento degli interi.
A me sembra tu stia assumendo che True sia un intero (dato che parli di
funzionamento degli interi) per concludere che deve essere un intero.
Io ti dico che non lo vorrei nemmeno considerato come tipo numerico, ma
come un generico tipo che fa il casting ad intero(/float) in modo
sensato nelle
Re: [Python] 0 in (False,) // 0 == False
On Fri, 05 Feb 2010 17:39:46 +0100, Pietro Battiston too...@email.it wrote: Per carità, dal punto di vista storico è chiaro, e non sto neanche facendo una battaglia perché si cambi: vorrei solo che si riconoscesse che non c'è nessun motivo assoluto per cui debba essere così. Ok, non c'era nessun motivo assoluto per cui dovesse essere così. Su questo hai ragione. Si sarebbe potuto fare: bool == int è sempre falso bool != int è sempre vero bool , , =, = int spara un'eccezione int(True) = 1 int(False) = 0 bool op int = int(bool) op int per ogni op aritmetica. Se invece i tipi funzionano con la semantica attuale è solo per convenzione e utilità. Se questa semantica è implementa come subclass è solo per comodità di implementazione. -- 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] 0 in (False,) // 0 == False
Il giorno ven, 05/02/2010 alle 17.53 +0100, Daniele Varrazzo ha scritto: On Fri, 05 Feb 2010 17:39:46 +0100, Pietro Battiston too...@email.it wrote: Per carità, dal punto di vista storico è chiaro, e non sto neanche facendo una battaglia perché si cambi: vorrei solo che si riconoscesse che non c'è nessun motivo assoluto per cui debba essere così. Ok, non c'era nessun motivo assoluto per cui dovesse essere così. Su questo hai ragione. Si sarebbe potuto fare: bool == int è sempre falso bool != int è sempre vero bool , , =, = int spara un'eccezione Solo in Python 3 :-) Pietro int(True) = 1 int(False) = 0 bool op int = int(bool) op int per ogni op aritmetica. Se invece i tipi funzionano con la semantica attuale è solo per convenzione e utilità. Se questa semantica è implementa come subclass è solo per comodità di implementazione. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
On Fri, Feb 05, 2010 at 05:53:01PM +0100, Daniele Varrazzo wrote: On Fri, 05 Feb 2010 17:39:46 +0100, Pietro Battiston too...@email.it wrote: Per carità, dal punto di vista storico è chiaro, e non sto neanche facendo una battaglia perché si cambi: vorrei solo che si riconoscesse che non c'è nessun motivo assoluto per cui debba essere così. Ok, non c'era nessun motivo assoluto per cui dovesse essere così. Su questo hai ragione. Si sarebbe potuto fare: bool == int è sempre falso bool != int è sempre vero bool , , =, = int spara un'eccezione int(True) = 1 int(False) = 0 bool op int = int(bool) op int per ogni op aritmetica. Se invece i tipi funzionano con la semantica attuale è solo per convenzione e utilità. Se questa semantica è implementa come subclass è solo per comodità di implementazione. Grazie per i chiarimenti e l'interessante discussione in particolare a Pietro e Daniele per l'analisi e gli esempi di supporto. Personalemnte mi pare chiaro che la prima citazione di Guido è perfettamente in linea con quanto scritto qui sopra... in attesa che Enrico mantenga la promessa e mostri gli assurdi completi che quanto scritto sopra comporterebbe. sandro *:-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
On 02/04/2010 10:26 AM, Alessandro Dentella wrote:
Ciao,
(solo) oggi mi sono imbattuto in 0 in (False,) che ha un comportamento
francamente controintuitivo:
In [1]: 0 in (False,)
Out[1]: True
che a sua volta dipende dal fatto che:
In [2]: 0 == False
Out[2]: True
Si', e' sempre stato cosi'. Anche prima che esistesse il tipo boolean,
True e False erano interi.
Mi viene qui di da chiedermi: ma che bisogno c'è che un booleano erediti da
un intero? piace a tutti che 0 == False sia vero?
A me piace.
Mi piace meno come si comporta javascript, dove 0 == false ma 0 !==
false, quindi i tipi sono distinti, come preferisci tu.
Ma tutti gli oggetti sono true, anche l'oggetto false (*):
0
0
Boolean(0)
false
Boolean(Boolean(0))
false
new Boolean(0)
false {}
Boolean(new Boolean(0))
true
new Boolean(new Boolean(0))
true {}
(*) ovvero, l'oggetto che wrappa false. argh
--
This e-mail (and any attachment(s)) is strictly confidential and for use only
by intended recipient(s). Any use, distribution, reproduction or disclosure by
any other person is strictly prohibited. The content of this e-mail does not
constitute a commitment by the Company except where provided for in a written
agreement between this e-mail addressee and the Company. If you are not an
intended recipient(s), please notify the sender promptly and destroy this
message and its attachments without reading or saving it in any manner. Any non
authorized use of the content of this message constitutes a violation of the
obligation to abstain from learning of the correspondence among other subjects,
except for more serious offence, and exposes the person responsible to the
relevant consequences.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
On Feb 4, 2010, at 10:26 AM, Alessandro Dentella wrote: Mi viene qui di da chiedermi: ma che bisogno c'è che un booleano erediti da un intero? piace a tutti che 0 == False sia vero? Non e' questione di ereditare in questo caso. Non mi da fastidio che un booleano sia il piu' piccolo tipo numerico che porta informazione. Un char e' un tipo numerico di (tipicamente) 8 bit. Perche' un booleano non puo' essere un tipo numerico di 1 bit? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
On Thu, Feb 04, 2010 at 11:04:59AM +0100, Enrico Franchi wrote: On Feb 4, 2010, at 10:26 AM, Alessandro Dentella wrote: Mi viene qui di da chiedermi: ma che bisogno c'è che un booleano erediti da un intero? piace a tutti che 0 == False sia vero? Non e' questione di ereditare in questo caso. ??? issubclass(bool, int) True Non sto testando che bool deriva da int? in che senso non è questione di ereditare Non mi da fastidio che un booleano sia il piu' piccolo tipo numerico che porta informazione. Questa però non mi pare la risposta a che bisogno c'è. Che non è una domana oziosa, è che immagino che ci *sia* bisogno in un modo che io ora non colgo. La domanda rifrasata sarebbe forse: quali sono le caratteristiche di un booleano che derivano da un intero? Riprendendo la tua risposta: che bisogno c'è che sia il più piccolo tipo *numerico* che porta informazione? sandro -- Sandro Dentella *:-) http://sqlkit.argolinux.orgSQLkit home page - PyGTK/python/sqlalchemy ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
On Thu, 4 Feb 2010 10:26:40 +0100, Alessandro Dentella san...@e-den.it
wrote:
Mi viene qui di da chiedermi: ma che bisogno c'è che un booleano erediti
da
un intero? piace a tutti che 0 == False sia vero?
A me piace... e mi piace ancora di più che 1 == True! In questo modo un
modo rapido per sapere quanti True hai in un insieme è sommare i valori
logici tra loro. O fare giochini tipo:
In [1]: def leggi_lati_triangolo():
...: return map(int, raw_input().split())
...:
In [2]: a, b, c = leggi_lati_triangolo()
3 4 4
In [3]: {0: 'scaleno', 1: 'isoscele', 3: 'equilatero'}[(a == b) + (b == c)
+ (a == c)]
Out[3]: 'isoscele'
In calcolo numerico si usa spesso moltiplicare una matrice numerica per
una matrice di booleani: la semplice moltiplicazione restituisce una
matrice che contiene solo i valori numerici corrispondenti ai vero dei
booleani. Perché dovrebbe essere più facile fare queste operazioni in C che
in Python? ;)
--
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] 0 in (False,) // 0 == False
On Thu, Feb 04, 2010 at 01:15:37PM +0100, Daniele Varrazzo wrote:
On Thu, 4 Feb 2010 10:26:40 +0100, Alessandro Dentella san...@e-den.it
wrote:
Mi viene qui di da chiedermi: ma che bisogno c'è che un booleano erediti
da
un intero? piace a tutti che 0 == False sia vero?
A me piace... e mi piace ancora di più che 1 == True! In questo modo un
modo rapido per sapere quanti True hai in un insieme è sommare i valori
logici tra loro. O fare giochini tipo:
In [1]: def leggi_lati_triangolo():
...: return map(int, raw_input().split())
...:
In [2]: a, b, c = leggi_lati_triangolo()
3 4 4
In [3]: {0: 'scaleno', 1: 'isoscele', 3: 'equilatero'}[(a == b) + (b == c)
+ (a == c)]
Out[3]: 'isoscele'
In calcolo numerico si usa spesso moltiplicare una matrice numerica per
una matrice di booleani: la semplice moltiplicazione restituisce una
matrice che contiene solo i valori numerici corrispondenti ai vero dei
booleani. Perché dovrebbe essere più facile fare queste operazioni in C che
in Python? ;)
Questo è avvincente come sostegno all'idea che il booleano si comporti comex
un intero. Ne deriva necessariamente che 0 == False? Ovvero: il fatto che
*si comporti come un numero* nell operazioni richiede per necessità che ==
dica che sono uguali?
Credo che la prima parte delle parole di guido indichino di no:
In an ideal world, bool might be better implemented as a separate
integer type that knows how to perform mixed-mode arithmetic
sandro
*:-)
--
Sandro Dentella *:-)
http://sqlkit.argolinux.orgSQLkit home page - PyGTK/python/sqlalchemy
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] 0 in (False,) // 0 == False
On Thu, 4 Feb 2010 13:36:25 +0100, Alessandro Dentella san...@e-den.it wrote: On Thu, Feb 04, 2010 at 01:15:37PM +0100, Daniele Varrazzo wrote: On Thu, 4 Feb 2010 10:26:40 +0100, Alessandro Dentella san...@e-den.it wrote: Mi viene qui di da chiedermi: ma che bisogno c'è che un booleano erediti da un intero? piace a tutti che 0 == False sia vero? A me piace... e mi piace ancora di più che 1 == True! In questo modo un ... Questo è avvincente come sostegno all'idea che il booleano si comporti comex un intero. Ne deriva necessariamente che 0 == False? Ovvero: il fatto che *si comporti come un numero* nell operazioni richiede per necessità che == dica che sono uguali? Credo che la prima parte delle parole di guido indichino di no: In an ideal world, bool might be better implemented as a separate integer type that knows how to perform mixed-mode arithmetic Mi sembra di capire che nel mondo ideale di Guido i bool sarebbero tipi separati dagli int mentre nel fangoso mondo reale ne sono una sottoclasse. Ma anche se fossero tipi interi separati, saprebbero effettuare operazioni aritmetiche miste: questo vuol dire che comunque saresti in grado di fare operazioni tipo int + bool. Ma sarebbe curioso se si potessero usare operatori misti aritmetici ma non logici, non trovi? Io penso sarebbe una limitazione artificiale. Avresti: implementazioni di int == int, di bool == bool ma non potresti usare int == bool. Proprio per la proprietà di trasparenza, per cui puoi facilmente scrivere codice in cui usare indifferentemente int o bool come input booleani, questa sarebbe una pericolosa asimmetria che porterebbe ad eccezioni misteriose. È proprio necessario che false sia 0? Probabilmente no (per le shell, 0 è true in contesto logico), ma in ogni caso, se puoi implementare operazioni logiche miste, tipo bool == int, false *deve* essere uguale ad almeno un intero: se False == X fosse sempre falso, vorrebbe dire che X è vero per ogni intero X, quindi praticamente non puoi usare gli interi come valori logici. Potevano scegliere -42 come False, ma cominceresti ad avere inconsistenze tra come si comportano il not logico e il not binario (operatore ~). Se vuoi verificare che un oggetto X sia davvero False e non 0, usa if X is False ;) -- 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] 0 in (False,) // 0 == False
On Feb 4, 2010, at 5:22 PM, Alessandro Dentella wrote: Asserzione gratuita con promessa di dimostrazione. Dimostrazione che non dubito esista, è infatti quella che andavo cercando... Guarda, è roba di algebra elementare. Se vuoi *veramente* che te la faccia, te la faccio pure. Roba da cinque minuti. Per me e per te, basta chiedere. Se posso evito di tediare il gruppo con svariate righe di banalità matematiche. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
