Re: [Python] Qu
On Feb 13, 2010, at 2:58 PM, Pietro Battiston wrote: > 2) argomentare con il fatto che se un programmatore, che è poi l'utente > del linguaggio, si trova ad utilizzare oggetti matematici - e.g. numeri > - dovranno comportarsi, per quanto possibile, come lui si aspetta. Sono d'accordo. Sotto ti faccio vedere come di fatto cose inaspettate salterebbero fuori comunque. > A volte l'1 pone dei vincoli necessari al 2; ciononostante del Python mi > piace che pone molta attenzione al 2 (vedi passare automaticamente da > int a long, perché di nuovo, quando come programmatore penso a "int" in > Python penso agli interi, non agli interi modulo INT_MAX). Come nota a margine, in C non hai sugli interi aritmetica modulare. Hai undefined behaviour quando sfori. L'aritmetica modulare la hai sugli unsigned (e quindi ocn UINT_MAX). Non che sia importante, solo una precisazione. >> sono considerate *cattiva* pratica. Proporre di abbandonare la pratica >> considerata "buona" di >> >> if []: >> >> IMHO non è particolarmente sensato. > > > Ma infatti non l'ho proposto, ed è la terza volta che cerco di > chiarirlo... Su questo punto quindi siamo d'accordo. In contesti di questo tipo 0 continuerebbe a valutare a False. Che poi, per dire, in effetti e' False che valuta a 0. Chi comanda e' il metodo __nonzero__, ma ok. >> Quindi spiegami meglio, tu proponi questa semantica. >> >> 0 != False -> True >> 0 == False -> False > > certo > >> >> Ora dimmi cosa vuoi fare in questi casi: >> >> 10 * False >> 10 + False > > il bool è convertito automaticamente in int ==> rispettivamente 0 e 10 Eh... poi ci troviamo con questo. Indichiamo con b un booleano, con n,m,... un intero e con a qualcosa che puo' essere indifferentemente un booleano o un intero. Il nostro obiettivo e' definire le operazioni su Bool U Int, rispettivamente l'insieme dei booleani e degli interi. Normalmente ci aspettiamo che: n + m - m == n siamo d'accordo? Lascio perdere le parentesi, poiche' in Python, grazie al "salto" a long abbiamo la proprieta' associativa. Supponiamo di estendere tale cosa agli "interi o booleani". Ricorda, vogliamo che i booleani si possano ancora usare al posto degli interi. False + m - m != False Infatti la prima parte viene convertita ad intera. False + m -> m ed m - m va a 0. Essenzialmente il problema e' che il nostro insieme Bool U Int si trova con due elementi neutri. L'algebra ci dice che se questi sono distinti non abbiamo piu' un gruppo, ovvero l'insieme (Bool U Int, +) non e' un gruppo. Questo e', in essenza, uno degli assurdi di cui parlavo. Per eliminare una cosa sgradevole matematicamente come avere False == 0, perdiamo alcune proprieta' fondamentali sulla struttura algebrica delle operazioni. Nota... per non dovere definire le operazioni su Bool U Int dobbiamo proibire l'aritmetica mista (come dicevo) oppure cambiare le proprita' di False e True, che non dovrebbero comportarsi come elementi cosi' particolari algebricamente come 0 ed 1. Il problema e' che non riusciamo a trovare nessun altro buon valore. Non possiamo metterli "in mezzo" fra due interi. Dobbiamo lasciare loro un valore tutto particolare e distinto da quello degli interi. Matematicamente si fa, voglio dire. A naso direi che ci imbatteremmo in qualche altro comportamento contro-intuitivo. Un'altra possibilita' e' intendere tutte le operazioni come operazioni su UxT dove U e' l'insieme di tutti i valori e T quello di tutti i tipi. Ma accidenti... IMHO viene proprio una cosa tosta. In questo senso mi sembra che la semplicita' di False e' praticamente un altro nome per 0 sia difficile da battere. >> 0 < False >> 0 > False >> 0 < True >> 0 > True >> > > Per come l'ho sostenuta sinora, semplicemente l'ordering tra tipi > diversi, ovvero int > bool in python 2.*, eccezione in python 3.* (se > non sbaglio). Poi preferisco la prima, ma questo è un altro discorso. Anche perche' se lanci eccezione, di fatto non e' vero che hai veramente "aritmetica" mista. Alcune operazioni "banali" che fai con gli interi (confronto) non puoi farle se uno dei due e' un booleano. > Sì. Non che veda niente di proibito in > > int < bool >definito come > int < int(bool) > > , ma non stavo pensavo a quello (che poi potrebbe essere pure più > comodo, non so). Sarebbe ovviamente l'unica scelta consistente con il "mischiare" interi e booleani. Quale e' il problema? A noi piace il principio del terzo escluso. Se due elementi non sono uno minore dell'altro (comunque li prendi), allora sono uguali. Eppure tu siccome vuoi che False "valuti" a 0 non puoi prenderlo ne minore ne maggiore di 0, ma di fatto non hai nemmeno 0 == False. Ovviamente, se per esempio prendi False > 0 poi ti saltano cose tipo 10 * False > 2 * False che a rigore dovresti avere. Questo perche' False continua a comportarsi come 0 e questo dovrebbe riflettersi nei confronti. > Ma ti rendi conto che per nessuno di questi valori in Python si è > ritenuto necessario introdurre un nuo
[Python] Organizziamo insieme il PyDayBO a Bologna , ospitato dalla facoltà di ingegneria!
Salve ragazz*! nel mese di Dicembre avevo scritto per sondare se ci fossero le disponibilità per organizare una giornata a tema Python per noi studenti della facoltà di Ingegneria di Bologna e più precisamente per gli aspiranti Ingegneri Informatici. Visto che la risposta fu molto buona, abbiamo deciso di organizzare davvero questo evento! La Data provvisoria (variabile a seconda delle disponibilità dei relatori) è il 10 MARZO Ci piacerebbe molto accogliere le offerte di Pietro Battiston (seminario pratico su python+gtk), Mr.SpOOn (PyKE) e Roberto Bettazzoni (Test Driven Development) Ribadisco er chi leggesse per la prima volta l'argomento: siamo un'associazione studentesca (indipendenti e NON ciellini!) della facoltà di Ingegneria di Bologna e ci offriamo di organizzare questa giornata ma cerchiamo qui relatori volontari disponibili a mostrarci il Python e le sue potenzialità! Tenete presente che il pubblico ha tendenzialmente una conoscenza di C e Java con rudimenti di C# E' necessario che la prima conferenza sia "Introduzione al Linguaggio Python: la sintassi e le particolarità" e si cercano volontari per tenerla! La giornata comincia alle 10:00 e si può protrarre fino alle 19! :D Aspetto volontari che ci offrano la disponibilità per fare una conferenza o un laboratorio (essendo fatto nella facoltà possiamo avere anche la disponibilità di un LAB)! grazie, Raffo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Qu
Il giorno dom, 14/02/2010 alle 10.39 +0100, Enrico Franchi ha scritto: > On Feb 13, 2010, at 2:58 PM, Pietro Battiston wrote: > > > > 2) argomentare con il fatto che se un programmatore, che è poi l'utente > > del linguaggio, si trova ad utilizzare oggetti matematici - e.g. numeri > > - dovranno comportarsi, per quanto possibile, come lui si aspetta. > > Sono d'accordo. Sotto ti faccio vedere come di fatto cose inaspettate > salterebbero fuori comunque. > > > A volte l'1 pone dei vincoli necessari al 2; ciononostante del Python mi > > piace che pone molta attenzione al 2 (vedi passare automaticamente da > > int a long, perché di nuovo, quando come programmatore penso a "int" in > > Python penso agli interi, non agli interi modulo INT_MAX). > > Come nota a margine, in C non hai sugli interi aritmetica modulare. Hai > undefined behaviour quando sfori. L'aritmetica modulare la hai sugli > unsigned (e quindi ocn UINT_MAX). Non che sia importante, solo una > precisazione. > > >> sono considerate *cattiva* pratica. Proporre di abbandonare la pratica > >> considerata "buona" di > >> > >> if []: > >> > >> IMHO non è particolarmente sensato. > > > > > > Ma infatti non l'ho proposto, ed è la terza volta che cerco di > > chiarirlo... > > Su questo punto quindi siamo d'accordo. In contesti di questo tipo 0 > continuerebbe a valutare a False. > Che poi, per dire, in effetti e' False che valuta a 0. Chi comanda e' > il metodo __nonzero__, ma ok. > > >> Quindi spiegami meglio, tu proponi questa semantica. > >> > >> 0 != False -> True > >> 0 == False -> False > > > > certo > > > >> > >> Ora dimmi cosa vuoi fare in questi casi: > >> > >> 10 * False > >> 10 + False > > > > il bool è convertito automaticamente in int ==> rispettivamente 0 e 10 > > Eh... poi ci troviamo con questo. Indichiamo con b un booleano, con n,m,... > un intero e con a qualcosa che puo' essere indifferentemente un booleano > o un intero. Il nostro obiettivo e' definire le operazioni su Bool U Int, > rispettivamente > l'insieme dei booleani e degli interi. ... con Bool ⊂ Int ? > > Normalmente ci aspettiamo che: > > n + m - m == n > > siamo d'accordo? No, è qui il punto, io mi rendo perfettamente conto che questo si perderebbe, ma non mi interessa, perché ... > Lascio perdere le parentesi, poiche' in Python, grazie al > "salto" a long abbiamo la proprieta' associativa. > > Supponiamo di estendere tale cosa agli "interi o booleani". Ricorda, vogliamo > che i booleani si possano ancora usare al posto degli interi. > > False + m - m != False ... perché una cosa così non la userei mai e poi mai: anche ammesso che dei valori di verità si possano _contare_ (sempre perché torna comodo), non li conto certamente con un booleano: prima che completamente antipythonico, è estremamente controintuitivo. A parlare in generale si rischia sempre, ma mi sento comunque di dire che _nessuno_ "conterebbe" davvero con un booleano: tutt'al più, quel che facciamo è contare _i_ booleani - cosa che si fa benissimo semplicemente con la conversione al volo di False in 0 e True in 1. Questo è un motivo per cui quanto scrivi sopra è ben lontano dallo scandalizzarmi. L'altro è che se veramente tu ritieni che n + m - m == n sia una regola sacrosanta che anche i booleani dovrebbero rispettare, allora In [1]: a = 5 In [2]: False + a - a Out[2]: 0 per me è scandaloso. Io vorrei leggere "False". Poi tu mi dici che è la stessa cosa, ma io sono convinto sia questione di abitudine e non si finisce più... > > Infatti la prima parte viene convertita ad intera. False + m -> m > ed m - m va a 0. Essenzialmente il problema e' che il nostro insieme > Bool U Int si trova con due elementi neutri. L'algebra ci dice che > se questi sono distinti non abbiamo piu' un gruppo, ovvero l'insieme > (Bool U Int, +) non e' un gruppo. Assolutamente. > Questo e', in essenza, uno degli assurdi di cui parlavo. Per eliminare una > cosa sgradevole matematicamente come avere False == 0, perdiamo > alcune proprieta' fondamentali sulla struttura algebrica delle operazioni. > Pensa che per me invece è assurdo (anche se formalmente impeccabile) che tu continui a chiamare (Bool U Int, +) una cosa che, finché parliamo matematicamente, è semplicemente (Int, +) dato che per come la vedi tu Bool ⊂ Int... > Nota... per non dovere definire le operazioni su Bool U Int dobbiamo > proibire l'aritmetica mista (come dicevo) oppure cambiare le proprita' > di False e True, che non dovrebbero comportarsi come elementi > cosi' particolari algebricamente come 0 ed 1. > > Il problema e' che non riusciamo a trovare nessun altro buon valore. > Non possiamo metterli "in mezzo" fra due interi. Dobbiamo lasciare > loro un valore tutto particolare e distinto da quello degli interi. > > Matematicamente si fa, voglio dire. A naso direi che ci imbatteremmo > in qualche altro comportamento contro-intuitivo. Un'altra possibilita' > e' intendere tutte le operazioni come opera
Re: [Python] Organizziamo insieme il PyDayBO a Bologna , ospitato dalla facoltà di ingegneria!
Il giorno dom, 14/02/2010 alle 11.27 +0100, Raffaele Serra ha scritto: > La Data provvisoria (variabile a seconda delle disponibilità dei > relatori) è il 10 MARZO segnato. Dovrei essere impegnato sul dopo pranzo, ma la mattina e il pomeriggio inoltrato è OK. > > Ci piacerebbe molto accogliere le offerte di Pietro Battiston > (seminario pratico su python+gtk), aggiudicato > [...] > > > E' necessario che la prima conferenza sia "Introduzione al Linguaggio > Python: la sintassi e le particolarità" e si cercano volontari per > tenerla! N.B: per me andava bene, avevo solo detto che verosimilmente gli altri relatori sono più esperti di me, e che inoltre io conosco C ma non C# e poco Java; comunque se vi torna comodo consideratemi come riserva. Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Organizziamo insieme il PyDayBO a Bologna , ospitato dalla facoltà di ingegneria!
Perfetto! :D Il giorno 14 febbraio 2010 11.45, Pietro Battiston ha scritto: > Il giorno dom, 14/02/2010 alle 11.27 +0100, Raffaele Serra ha scritto: > > > La Data provvisoria (variabile a seconda delle disponibilità dei > > relatori) è il 10 MARZO > > segnato. > > Dovrei essere impegnato sul dopo pranzo, ma la mattina e il pomeriggio > inoltrato è OK. > > > > > Ci piacerebbe molto accogliere le offerte di Pietro Battiston > > (seminario pratico su python+gtk), > > aggiudicato > > > [...] > > > > > > E' necessario che la prima conferenza sia "Introduzione al Linguaggio > > Python: la sintassi e le particolarità" e si cercano volontari per > > tenerla! > > N.B: per me andava bene, avevo solo detto che verosimilmente gli altri > relatori sono più esperti di me, e che inoltre io conosco C ma non C# e > poco Java; comunque se vi torna comodo consideratemi come riserva. > > Pietro > > > ___ > 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] Qu
2010/2/14 Pietro Battiston : > Non intendo certo arrogarmi il diritto di definirmi *informatico* (non > lo sono né di formazione né di professione)... quindi i casi sono 2: Credo che il fatto che siate entrambi di formazione matematica non sia sfuggito al piu` distratto dei presenti ;) E lo humor che pervade questo thread mi fa pensare anche che avete entrambi studiato haskell... /me si nasconde Cheers, © -- Carlo C8E Miron No Fun No Math Solution Architect™ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Qu
On Feb 14, 2010, at 11:38 AM, Pietro Battiston wrote: >> Eh... poi ci troviamo con questo. Indichiamo con b un booleano, con n,m,... >> un intero e con a qualcosa che puo' essere indifferentemente un booleano >> o un intero. Il nostro obiettivo e' definire le operazioni su Bool U Int, >> rispettivamente >> l'insieme dei booleani e degli interi. > > ... con Bool ⊂ Int ? Dipende. Nel python attuale si, nel "tuo" python ovviamente no. >> Normalmente ci aspettiamo che: >> >> n + m - m == n >> siamo d'accordo? >> False + m - m != False > No, è qui il punto, io mi rendo perfettamente conto che questo si > perderebbe, ma non mi interessa, perché ... > ... perché una cosa così non la userei mai e poi mai Questo poco importa. Mi spiego, il fatto che tu od io pensiamo che usare una data feature del linguaggio (esplicitamente) non sia una buona idea, e' irrilevante. Di fatto quello che otteniamo e' che la nuova struttura algebrica, che abbiamo voluto per togliere una piccola bruttura, e' un orrido. Permettermi ma trovarci con una cosa che non e' manco un gruppo per togliere identita' fra False e 0 mi sembra una cura peggiore del male. Il fatto che tu consideri o meno quel codice sensato non toglie che sia perfettamente valido e di conseguenza tutto il codice scritto assumendo proprieta' ragionevoli come quelle la sopra diventa automaticamente *sbagliato*. > : anche ammesso che > dei valori di verità si possano _contare_ (sempre perché torna comodo), > non li conto certamente con un booleano: prima che completamente > antipythonico, è estremamente controintuitivo. A parlare in generale si > rischia sempre, ma mi sento comunque di dire che _nessuno_ "conterebbe" > davvero con un booleano: tutt'al più, quel che facciamo è contare _i_ > booleani - cosa che si fa benissimo semplicemente con la conversione al > volo di False in 0 e True in 1. Quando progetti un linguaggio non puoi dire... si, questa feature del linguaggio e' sbagliata e porta ad assurdi, ma tanto nessuno vuole veramente usarla. Perche' qualcuno che la usera' ci sara'. E ne verrebbero fuori thread ben peggiori di questo. Per togliere un "fastidio" (avere due oggetti diversi con lo stesso comportamento) ci troviamo con tutta la struttura matematica dei tipi interi a mare. > Questo è un motivo per cui quanto scrivi sopra è ben lontano dallo > scandalizzarmi. L'altro è che se veramente tu ritieni che > n + m - m == n > sia una regola sacrosanta che anche i booleani dovrebbero rispettare, > allora > > In [1]: a = 5 > > In [2]: False + a - a > Out[2]: 0 > > per me è scandaloso. Io vorrei leggere "False". Poi tu mi dici che è la > stessa cosa, ma io sono convinto sia questione di abitudine e non si > finisce più... Non ho parlato di "regole sacrosante". Tuttavia mi sembra ragionevole, no? E' talmente poco sacrosanto che in C non me lo aspetto e non vale. Ma non e' che sia una buona cosa, voglio dire. Non me lo aspetto nemmeno con i float. Ma visto che in Python abbiamo interi illimitati (essenzialmente), quella cosa li posso aspettarmela. Il fatto di perderla mi infastidisce molto piu' di 0 == False. Questa cosa poi non e' questione di "abitudine". Tu insisti su quello che stampa. A me quello che stampa interessa veramente poco: mi interessa la semantica della computazione. Da un lato ho una cosa stampata che mi piace poco, dall'altra ho codice rotto. Per me non sono due cose sullo stesso piano. > Pensa che per me invece è assurdo (anche se formalmente impeccabile) che > tu continui a chiamare > (Bool U Int, +) > una cosa che, finché parliamo matematicamente, è semplicemente > (Int, +) > dato che per come la vedi tu Bool ⊂ Int... Non e' per come la vedo io, e' per come la vede Python. Per inciso, ho tenuto le cose distinte, perche' stiamo parlando di questo ipotetico nuovo Python con le tue regole. E in questo Python quello che stiamo andando a fare e' definire le operazioni in Bool U Int. > Tu mi dici "ma non è giusto, i bool sono numeri come gli altri!". > Io dico di no. No. Qui la faccenda e' andata oltre. Se non vuoi che i booleani siano interi, posso accettarlo. Allora ci saranno eccezioni esattamente come se sommi stringhe ed interi. Come fa Ruby. Questo e' un comportamento coerente. IMHO e' meno comodo, ma e' completamente sound e robusto. Nel momento in cui decidiamo di dare semantica di somma ai booleani (che tu vuoi) tiriamo fuori i problemi di cui sopra. > E questa è una differenza di opinione che non ha giustificazioni > formali: a seconda di come sei abituato a concepire il concetto di > booleano, alcune cose ti sembrano più controintuitive di altre. Io ti sto dicendo: ci sono due mondi. Uno assolutamente inattaccabile (quello di Ruby) e uno piu' pragmatico che e' come fa Python. Nota, se anche i bool in Python non *fossero* numeri, ma si comportassero come numeri, 0 == False dovrebbe dare comunque True. Il mondo che tu proponi, e' quello in cui perdi praticamente tutte le proprieta' algebriche util
Re: [Python] 0 in (False,) // 0 == False (era: Re: Qu)
Il giorno dom, 14/02/2010 alle 12.26 +0100, Enrico Franchi ha scritto: > On Feb 14, 2010, at 11:38 AM, Pietro Battiston wrote: > > >> Eh... poi ci troviamo con questo. Indichiamo con b un booleano, con n,m,... > >> un intero e con a qualcosa che puo' essere indifferentemente un booleano > >> o un intero. Il nostro obiettivo e' definire le operazioni su Bool U Int, > >> rispettivamente > >> l'insieme dei booleani e degli interi. > > > > ... con Bool ⊂ Int ? > > Dipende. Nel python attuale si, nel "tuo" python ovviamente no. > > >> Normalmente ci aspettiamo che: > >> > >> n + m - m == n > >> siamo d'accordo? > >> False + m - m != False > > No, è qui il punto, io mi rendo perfettamente conto che questo si > > perderebbe, ma non mi interessa, perché ... > > ... perché una cosa così non la userei mai e poi mai > > Questo poco importa. Mi spiego, il fatto che tu od io pensiamo che usare > una data feature del linguaggio (esplicitamente) non sia una buona idea, > e' irrilevante. > > Di fatto quello che otteniamo e' che la nuova struttura algebrica, che abbiamo > voluto per togliere una piccola bruttura, e' un orrido. Permettermi ma > trovarci > con una cosa che non e' manco un gruppo per togliere identita' fra False e > 0 mi sembra una cura peggiore del male. > > Il fatto che tu consideri o meno quel codice sensato non toglie che sia > perfettamente valido e di conseguenza tutto il codice scritto assumendo > proprieta' ragionevoli come quelle la sopra diventa automaticamente > *sbagliato*. > > > > : anche ammesso che > > dei valori di verità si possano _contare_ (sempre perché torna comodo), > > non li conto certamente con un booleano: prima che completamente > > antipythonico, è estremamente controintuitivo. A parlare in generale si > > rischia sempre, ma mi sento comunque di dire che _nessuno_ "conterebbe" > > davvero con un booleano: tutt'al più, quel che facciamo è contare _i_ > > booleani - cosa che si fa benissimo semplicemente con la conversione al > > volo di False in 0 e True in 1. > > Quando progetti un linguaggio non puoi dire... si, questa feature del > linguaggio > e' sbagliata e porta ad assurdi, ma tanto nessuno vuole veramente usarla. > Perche' qualcuno che la usera' ci sara'. > > E ne verrebbero fuori thread ben peggiori di questo. Per togliere un > "fastidio" > (avere due oggetti diversi con lo stesso comportamento) ci troviamo con tutta > la struttura matematica dei tipi interi a mare. > > > > Questo è un motivo per cui quanto scrivi sopra è ben lontano dallo > > scandalizzarmi. L'altro è che se veramente tu ritieni che > > n + m - m == n > > sia una regola sacrosanta che anche i booleani dovrebbero rispettare, > > allora > > > > In [1]: a = 5 > > > > In [2]: False + a - a > > Out[2]: 0 > > > > per me è scandaloso. Io vorrei leggere "False". Poi tu mi dici che è la > > stessa cosa, ma io sono convinto sia questione di abitudine e non si > > finisce più... > > Non ho parlato di "regole sacrosante". Tuttavia mi sembra ragionevole, no? > E' talmente poco sacrosanto che in C non me lo aspetto e non vale. Ma non > e' che sia una buona cosa, voglio dire. Non me lo aspetto nemmeno con i > float. > > Ma visto che in Python abbiamo interi illimitati (essenzialmente), quella cosa > li posso aspettarmela. Il fatto di perderla mi infastidisce molto piu' di 0 > == False. > > Questa cosa poi non e' questione di "abitudine". Tu insisti su quello che > stampa. > A me quello che stampa interessa veramente poco: mi interessa la semantica > della computazione. Da un lato ho una cosa stampata che mi piace poco, > dall'altra ho codice rotto. Per me non sono due cose sullo stesso piano. > > > Pensa che per me invece è assurdo (anche se formalmente impeccabile) che > > tu continui a chiamare > > (Bool U Int, +) > > una cosa che, finché parliamo matematicamente, è semplicemente > > (Int, +) > > dato che per come la vedi tu Bool ⊂ Int... > > Non e' per come la vedo io, e' per come la vede Python. Per inciso, ho tenuto > le cose distinte, perche' stiamo parlando di questo ipotetico nuovo Python con > le tue regole. E in questo Python quello che stiamo andando a fare e' definire > le operazioni in Bool U Int. > > > Tu mi dici "ma non è giusto, i bool sono numeri come gli altri!". > > Io dico di no. > > No. Qui la faccenda e' andata oltre. Se non vuoi che i booleani siano interi, > posso accettarlo. Allora ci saranno eccezioni esattamente come se sommi > stringhe ed interi. Come fa Ruby. Questo e' un comportamento coerente. > IMHO e' meno comodo, ma e' completamente sound e robusto. > > Nel momento in cui decidiamo di dare semantica di somma ai booleani > (che tu vuoi) tiriamo fuori i problemi di cui sopra. > > > E questa è una differenza di opinione che non ha giustificazioni > > formali: a seconda di come sei abituato a concepire il concetto di > > booleano, alcune cose ti sembrano più controintuitive di altre. > > Io ti sto dicendo: ci sono due mondi. Uno assolutament
Re: [Python] Qu
On Feb 14, 2010, at 12:14 PM, Carlo C8E Miron wrote: > Credo che il fatto che siate entrambi di formazione matematica non sia > sfuggito al piu` distratto dei presenti ;) > E lo humor che pervade questo thread mi fa pensare anche che avete > entrambi studiato haskell... Ah, LOL... sta cosa di Haskell mi perseguita! Quello e' Manlio! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Approccio agli oggetti
Grazie a tutti,
i vostri consigli mi sono stati molto utili..
quindi vi posto il nuovo codice.. :)
#!/usr/bin/python
import os, myStringTool
class FilePrelievo(file):
def __init__(self,FileName):
self.myfile = open(FileName,'r')
self.dataSet=[]
self.linea=[]
def leggiLinea(self):
linea=self.myfile.readline()
l=linea.split(';')
newlista=[]
for x in l:
x=myStringTool.cleanInizio(x)
x=myStringTool.cleanFine(x)
newlista.append(x)
return newlista
def importaFile(self):
while self.linea<>['']:
self.linea=self.leggiLinea()
self.dataSet.append(self.linea)
if self.dataSet[-1]==['']:
self.dataSet=self.dataSet[:-1]
def stampa(self,myfile):
print >>
myfile,"---"
for i in range(len(self.dataSet)):
print >> myfile,"! %s ! %s ! %s ! %s ! %s !" % \
(myStringTool.optString(self.dataSet[i][0],12),\
myStringTool.optString(self.dataSet[i][1],5),\
myStringTool.optString(self.dataSet[i][2],12),\
myStringTool.optString(self.dataSet[i][3],12),\
myStringTool.optString(self.dataSet[i][4],2))
print >> myfile,
"---"
prelievo=FilePrelievo('/home/diego/Scrivania/IndirizziCIP.csv')
prelievo.importaFile()
myfile=open('/home/diego/Scrivania/IndirizziCIP2.csv','w')
prelievo.stampa(myfile)
myfile.close
myfile=open('/home/diego/Scrivania/IndirizziCIP2.csv','r')
printer=os.popen('lpr','w')
printer.write(myfile.read())
<\code>
invece dentro myStringTool:
def cleanInizio(mystring):
if mystring=='': return mystring
if (mystring[0]==' ') :
mystring = cleanInizio(mystring[1:])
return mystring
else:
return mystring
def cleanFine(mystring):
if mystring=='': return mystring
if (mystring[-1]==' ') or (mystring[-1]=='\n') :
mystring = cleanFine(mystring[:-1])
return mystring
else:
return mystring
def optString(stringa, lunghezza):
blank=' ' * lunghezza
stringa= (stringa + blank) [0:lunghezza]
return stringa
<\code>
Ciao a tutti
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Organizziamo insieme il PyDayBO a Bologna , ospitato dalla facoltà di ingegneria!
Il giorno 14 febbraio 2010 11.27, Raffaele Serra ha scritto: > Salve ragazz*! > nel mese di Dicembre avevo scritto per sondare se ci fossero le > disponibilità per organizare una giornata a tema Python per noi studenti > della facoltà di Ingegneria di Bologna e più precisamente per gli aspiranti > Ingegneri Informatici. > > Visto che la risposta fu molto buona, abbiamo deciso di organizzare davvero > questo evento! > La Data provvisoria (variabile a seconda delle disponibilità dei relatori) > è il 10 MARZO > > Ci piacerebbe molto accogliere le offerte di Pietro Battiston (seminario > pratico su python+gtk), Mr.SpOOn (PyKE) e Roberto Bettazzoni (Test > Driven Development) > > Ribadisco er chi leggesse per la prima volta l'argomento: siamo > un'associazione studentesca (indipendenti e NON ciellini!) della facoltà di > Ingegneria di Bologna e ci offriamo di organizzare questa giornata ma > cerchiamo qui relatori volontari disponibili a mostrarci il Python e le sue > potenzialità! Tenete presente che il pubblico ha tendenzialmente una > conoscenza di C e Java con rudimenti di C# > > E' necessario che la prima conferenza sia "Introduzione al Linguaggio > Python: la sintassi e le particolarità" e si cercano volontari per tenerla! > > La giornata comincia alle 10:00 e si può protrarre fino alle 19! :D > > Aspetto volontari che ci offrano la disponibilità per fare una conferenza o > un laboratorio (essendo fatto nella facoltà possiamo avere anche la > disponibilità di un LAB)! > > > grazie, > Raffo > Ciao, io sono uno uno studente di ing. informatica (nel tempo libero ;-)) lì a Bologna ma soprattutto sono il responsabile dei Servizi Informatici di uno comune dell'hinterland bolognese. Per lavoro ultimamente uso molto Django (framework web in Python) e se interessa posso fare un talk su di esso. Un saluto -- Simo - Registered Linux User #395060 - Software is like sex, it is better when it is free --> Linus B. Torvalds ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
