Re: [Python] Dubbi su hash e set
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 enrico franchi ha scritto: > On Fri, May 2, 2008 at 8:46 PM, Pietro Battiston <[EMAIL PROTECTED]> wrote: > >> Ora, la mia coscienza sporca mi suggerisce che forse quando ho >> sovrascritto __hash__ ho fatto più di quanto dovrebbe fare uno che di >> internal Python non ne sa abbastanza, e che le hash di tutti gli >> oggetti che conosco sono (solitamente) univoche. Ma... > > Non è questione di internals. E' questione di algoritmi. Devi definire > una funzione (quasi) univoca sugli oggetti che a te interessano. > La proprietà è che se hash(x) == hash(y) per te x e y devono essere > uguali e che possibilmente se devono essere diversi non abbiano lo > stesso hash (che vuole dire "è estremamente poco probabile che..."). OK, allora i miei scrupoli erano ingiustificati e stavo effettivamente agendo "legalmente". Quindi?! >> "not necessarily true" non significa che dovrebbe alla fine fregarsene >> se in un insieme due elementi distinti (e peraltro identici in tutto >> tranne l'allocazione di memoria) hanno la stessa hash?! > > Dice chiaramente: due valori con lo stesso valore hanno anche lo stesso hash, > due valori con diverso hash potrebbero avere lo stesso valore (o anche > no). E' frequente: per esempio se crei una classe "vuota" tutte le sue > istanze avranno lo stesso hash (se la prova non mi inganna). In realtà qualche osservazione empirica mi fa pensare che in caso di __hash__ non definita, hash(x) = id(x). Comunque ho afferrato il concetto. >> Qualcunque schiarimento è graditissimo, scusate la chilometricità >> della mail. > > Io tutt'ora non ho capito quale sia il tuo problema. Il mio problema è quello che avevo scritto all'inizio: In [6]: [v for v in penta.v][0] in penta.v Out[6]: False Il primo elemento di penta.v è, evidentemente, in penta.v. Perché risponde False?!? Daniele, che ringrazio e di cui condenso la risposta in una sola email per praticità di lettura, ha risposto: Daniele Varrazzo ha scritto: > Gli oggetti nel tuo insieme dovrebbero essere immutabili. Se cambi un oggetto, > e come conseguenza del cambiamento il suo hash cambia, hai tranqillamente una > situazione come quella indicata. In effetti i miei oggetti non sono immutabili. Ma non capisco come questo primo elemento di penta.v potrebbe essere modificato dalla sola operazione di estrazione da un insieme che lo contiene. E se anche per assurdo fosse possibile, il seguente output: In [12]: hash([v for v in penta.v][0]) Out[12]: 0 In [14]: map(hash, penta.v) Out[14]: [0, 5, 8, 11, 14, 17, 22, 25, 28, 0] mi conferma che non c'è stato proprio nessun cambiamento, perlomeno nel valore di hash. Anche se mi rendo conto che se un cambiamento c'è, potrebbe essere avvenuto in entrambi i casi nel momento di iterare sull'insieme. Ma di nuovo: cosa potrebbe mai cambiare?! >> (N.B: la funzione __hash__ di "vertex" l'ho ridefinita io) > > Come hai definito l'hash? Questa è l'informazione più importante. Per com'è fatta, non chiarirebbe granché. Eccovi quindi tutta la classe, tanto è piccolina: class vertex(set): valid = True def __init__(self, *args): set.__init__(self,*args) self.ID = new_ID() def __hash__(self): return self.ID def delete(self): ''' Doesn't really delete a vertex: it marks it as deletable. ''' self.clear() self.ID = 0 self.valid = False def __repr__(self): return "(vertex %d - edges %s)" % (self.ID, list.__repr__([e.ID for e in self])) new_ID() è un generatore che restituisce i numeri naturali in ordine. Quindi ogni istanza della classe ha un valore di hash diverso, tranne quelle su cui è stato chiamato "delete", che restituiscono 0. N.B: ho ridefinito __hash__ proprio perché "set objects are unhashable" > >> hash(object) -> integer >> >> Return a hash value for the object. Two objects with the same >> value have >> the same hash value. The reverse is not necessarily true, but likely. >> >> >> "not necessarily true" non significa che dovrebbe alla fine fregarsene >> se in un insieme due elementi distinti (e peraltro identici in tutto >> tranne l'allocazione di memoria) hanno la stessa hash?! > > Quante più collisioni ci sono, tanto più l'accesso alla mappa smetterà di > essere o(1) e diventerà o(n). Se tutti gli oggetti hanno lo stesso hash, > cercare in un dizionario che ha tali oggetti per chiave è come cercare per > uguaglianza in una lista non ordinata. > Lo immaginavo. Ma la performance in questo caso non mi preoccupa, perché gli elementi con hash=0 (e quindi uguale tra di loro) nei miei programmini sono pochi e hanno vita breve. > Già che ci sono: c'è un modo più semplice/furbo di: > > elemento = [v for v in insieme][0] > oppure: > elemento = insieme.pop(); insieme.add(elemento) > > per ottenere un qualsiasi elemento di un insieme dato tenendolo > nell'insieme? Ad esempio iter(insieme).next() Grazie mille...
Re: [Python] Dubbi su hash e set
Pietro Battiston ha scritto: > Daniele Varrazzo ha scritto: >> Gli oggetti nel tuo insieme dovrebbero essere immutabili. Se cambi un > oggetto, >> e come conseguenza del cambiamento il suo hash cambia, hai > tranqillamente una >> situazione come quella indicata. > > In effetti i miei oggetti non sono immutabili. Ma non capisco come > questo primo elemento di penta.v potrebbe essere modificato dalla sola > operazione di estrazione da un insieme che lo contiene. E se anche per > assurdo fosse possibile, il seguente output: > > In [12]: hash([v for v in penta.v][0]) > Out[12]: 0 > > In [14]: map(hash, penta.v) > Out[14]: [0, 5, 8, 11, 14, 17, 22, 25, 28, 0] > > > mi conferma che non c'è stato proprio nessun cambiamento, perlomeno > nel valore di hash. Anche se mi rendo conto che se un cambiamento c'è, > potrebbe essere avvenuto in entrambi i casi nel momento di iterare > sull'insieme. Ma di nuovo: cosa potrebbe mai cambiare?! Probabilmente il "primo" (quello corrispondente a list(penta)[0]) elemento dell'insieme è stato messo nell'insieme prima di essere cancellato (quando il suo hash era != 0). Non ho potuto controllare il codice perché la url di "poly.txt" che hai allegato in fondo al messaggio è rotta. > new_ID() è un generatore che restituisce i numeri naturali in ordine. > Quindi ogni istanza della classe ha un valore di hash diverso, tranne > quelle su cui è stato chiamato "delete", che restituiscono 0. Forse non ti è chiaro come funziona un dizionario e perchè i set (o le liste) non siano hashabili (un motivo c'è, non è un limite arbitrario!) Un dict (un set è uguale, puoi vederlo come un dict in cui le chiavi e i valori sono uguali) è una struttura di dati divisa in "secchi" (bin). L'inserimento di un oggetto in un dict consiste in: - scegliere il bin - e questo si fa leggendo l'hash della chiave. - inserire l'oggetto nel bin (potrebbe non essere il solo: diciamo che ogni bin è una lista) La ricerca di una chiave consiste invece in: - scegliere il bin come sopra - estraendo l'hash della chiave - cercare in tutti gli oggetti nel bin quello che ha la chiave uguale. Se lo trovi, hai trovato l'oggetto Secondo me tu metti un oggetto nel set, poi ne chiami delete(). Riesci a vedere che succede? Lo stesso oggetto ha cambiato hash (si vede perché è 0: vuol dire che ne hai chiamato delete()), il che vuol dire che, inserito nel dict, sarebbe finito in un secchio diverso. Per questo la ricerca fallisce: quando testi "elemento in insieme" dove hash(elemento) == 0 ma hash(elemento) era != 0 quando ce l'avevi messo, cerchi probabilmente l'elemento nel bin sbagliato. E non lo trovi. >> Già che ci sono: c'è un modo più semplice/furbo di: >> >> elemento = [v for v in insieme][0] >> oppure: >> elemento = insieme.pop(); insieme.add(elemento) >> >> per ottenere un qualsiasi elemento di un insieme dato tenendolo >> nell'insieme? > > Ad esempio iter(insieme).next() > > Grazie mille... adesso almeno ho comando più semplice su cui impazzire: LOL :) Quello che fai con iter(insieme) (o gli altri modi diversi di iterare sul dict) non è una ricerca per chiave, ma una navigazione in tutto il contenuto, operazione che non consiste nella lettura dell'hash e che funziona anche nel tuo set, che è in uno stato inconsistente. Ma nel momento in cui usi l'operatore "in" stai facendo una ricerca per chave: se l'hash è cambiato, e con esso il bin, l'oggetto non viene trovato nel dict. > Ma c'è di peggio: > ... > > Ovvero il solo atto di "poppare" un elemento e rimetterlo > immediatamente nell'insieme cambia qualcosa ed elimina il mio problema! Forse ora ti è chiaro perchè. pop() non usa le chiavi, ma tira fuori il primo che gli capita (come iter()). L'oggetto viene rimosso dal set. Quando fai add(), l'hash dell'oggetto viene ricalcolato e il bin viene aggiornato: il dict è tornato in stato consistente (ma può sempre tornare inconsistente!) Insomma, se vuoi usare oggetti come chiavi, non c'è nessun'altra possibilità se non quella di avere chiavi immutabili. Per questo set e list non possono esserlo ma tuple si. Nota anche che esiste frozenset che è un insieme immutabile e pensato appositamente per essere hashabile. La magia dell'accesso o(1) dei dict e dei set è condizionata dal fatto che deve essere possibile calcolare un hash sulle chiavi, e che questo hash sia immutabile. Nota che anche il "valore" delle chiavi (quello che tu usi per comparare con uguaglianza, quando dici o1 == o2) deve essere altrettanto immutabile. Altre proprietà delle chiavi possono cambiare, ma non quelle che usi per implementare __hash__() ed __eq__(). Se queste condizioni non si applicano ai tuoi oggetti, devi mettere gli oggetti in una lista ed accontentarti di una ricerca o(n) su di essi. Ti sembra un limite arbitrario? diciamo che tu sei furbo, non conosci gli hash ma le tue chiavi sono ordinabili. Allora implementi una bella ricerca per bisezione su una lista ordinata. Perchè la ricerca funzioni de
Re: [Python] Dubbi su hash e set
Daniele Varrazzo ha scritto: > Pietro Battiston ha scritto: > > >> Daniele Varrazzo ha scritto: >> >>> Gli oggetti nel tuo insieme dovrebbero essere immutabili. Se cambi un >>> >> oggetto, >> >>> e come conseguenza del cambiamento il suo hash cambia, hai >>> >> tranqillamente una >> >>> situazione come quella indicata. >>> >> In effetti i miei oggetti non sono immutabili. Ma non capisco come >> questo primo elemento di penta.v potrebbe essere modificato dalla sola >> operazione di estrazione da un insieme che lo contiene. E se anche per >> assurdo fosse possibile, il seguente output: >> >> In [12]: hash([v for v in penta.v][0]) >> Out[12]: 0 >> >> In [14]: map(hash, penta.v) >> Out[14]: [0, 5, 8, 11, 14, 17, 22, 25, 28, 0] >> >> >> mi conferma che non c'è stato proprio nessun cambiamento, perlomeno >> nel valore di hash. Anche se mi rendo conto che se un cambiamento c'è, >> potrebbe essere avvenuto in entrambi i casi nel momento di iterare >> sull'insieme. Ma di nuovo: cosa potrebbe mai cambiare?! >> > > Probabilmente il "primo" (quello corrispondente a list(penta)[0]) elemento > dell'insieme è stato messo nell'insieme prima di essere cancellato (quando il > suo hash era != 0). Non ho potuto controllare il codice perché la url di > "poly.txt" che hai allegato in fondo al messaggio è rotta. > ... ma ti garantisco che è in effetti era proprio come dici tu! >> new_ID() è un generatore che restituisce i numeri naturali in ordine. >> Quindi ogni istanza della classe ha un valore di hash diverso, tranne >> quelle su cui è stato chiamato "delete", che restituiscono 0. >> > > Forse non ti è chiaro come funziona un dizionario e perchè i set (o le liste) > non siano hashabili (un motivo c'è, non è un limite arbitrario!) > Mi ero risposto che se un set fosse stato hashabile avrebbe potuto contenere anche se stesso, per cui le funzioni __hash__ e soprattutto __repr__ ed __eq__ avrebbero avuto seri problemi. In realtà poi mi sono accorto che forzando una funzione __hash__ stupida su liste e set, l'interprete maneggia in modo egregio la ricorsività "infinita". > Secondo me tu metti un oggetto nel set, poi ne chiami delete(). Riesci a > vedere che succede? Sì. E il bello è che come funziona una hash table lo sapevo. Solo che mi illudevo che questo meccanismo fosse un modo per fare una prima ricerca, seguita, in caso di fallimento, da una eventuale ricerca in tempo O(n). Cosa che invece - ma ci ho pensato solo a posteriori - non avrebbe senso perché ogni "in" che restituisca False prenderebbe O(n) tempo. >> Ma c'è di peggio: >> ... >> >> Ovvero il solo atto di "poppare" un elemento e rimetterlo >> immediatamente nell'insieme cambia qualcosa ed elimina il mio problema! >> > > Forse ora ti è chiaro perchè. Già. > pop() non usa le chiavi, ma tira fuori il primo > che gli capita (come iter()). L'oggetto viene rimosso dal set. Quando fai > add(), l'hash dell'oggetto viene ricalcolato e il bin viene aggiornato: il > dict è tornato in stato consistente (ma può sempre tornare inconsistente!) > ... per giunta nel mio caso ci restava inconsistente, perché c'era un altro elemento simile; però tanto bastava a darmi la risposta che mi faceva felice... > Per questo set e list non possono > esserlo ma tuple si. Nota anche che esiste frozenset che è un insieme > immutabile e pensato appositamente per essere hashabile. > In realtà poi al mio codice bastava una modifica minima: evitare che "delete" azzeri self.ID: gli oggetti rimangono non immutabili ma il valore di hash è dato dalla loro "parte immutabile". > Tutto chiaro? > Ora sì, grazie mille! Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Consiglio su utilizzo di variabili globali
On Sat, May 3, 2008 at 4:33 PM, Mr. SpOOn <[EMAIL PROTECTED]> wrote: > In effetti avevo pensato proprio a una cosa simile. Come mai è meglio > lasciarli perdere? Perchè non fanno assolutamente nulla. Se devi scrivere una funzione per fare un assegnamento, scrivi l'assegnamento e basta. Quella dei setter/getter banali è una mania dei Javisti che sarebbe bene non fare proliferare ulteriormente. -- -enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Parsing output dei comandi
2008/5/1 Mattia <[EMAIL PROTECTED]>: > Vorrei provare questa strada. Se hai dei link da passare che hai > trovato particolarmente interessanti... Io userei PLY. Ma mi sa che sono biased, eh. -- -enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dubbi su hash e set
Pietro Battiston ha scritto: > In realtà poi al mio codice bastava una modifica minima: evitare che > "delete" azzeri self.ID: gli oggetti rimangono non immutabili ma il > valore di hash è dato dalla loro "parte immutabile". Già, ma in questo caso l'uguaglianza è data dal contenuto (usi set.__eq__). Quindi puoi avere due oggetti uguali ma con hash diverso, che è contrario alla semantica che dict si aspetta dall'hash (due oggetti uguali devono avere lo stesso hash). Quindi non sono sicuro che tu abbia risolto il tuo problema, a meno che non implementi anche: def __eq__(self, other): return self.ID == other.ID (e tanto vale usare la funzione id() a questo punto). -- 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] Consiglio su utilizzo di variabili globali
enrico franchi ha scritto: > On Sat, May 3, 2008 at 4:33 PM, Mr. SpOOn <[EMAIL PROTECTED]> wrote: > >> In effetti avevo pensato proprio a una cosa simile. Come mai è meglio >> lasciarli perdere? > > Perchè non fanno assolutamente nulla. Se devi scrivere una funzione > per fare un assegnamento, scrivi l'assegnamento e basta. > Quella dei setter/getter banali è una mania dei Javisti che sarebbe > bene non fare proliferare ulteriormente. Penserei la stessa cose se stesse accedendo alla proprietà di un oggetto, per cui usi direttamente la variabile e, quando questo non ti basta più, puoi sostituirla con una proprietà. Ma una variabile di modulo non puoi sostituirla con una proprietà, quindi io mi terrei stretto il getter. Ci sono un sacco di situazioni in cui fa comodo: - inizializzare il valore al suo primo accesso - consentire la lettura ma non la scrittura - serializzare gli accessi ...eccetera. -- 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] Dubbi su hash e set
Daniele Varrazzo ha scritto: > Pietro Battiston ha scritto: > > >> In realtà poi al mio codice bastava una modifica minima: evitare che >> "delete" azzeri self.ID: gli oggetti rimangono non immutabili ma il >> valore di hash è dato dalla loro "parte immutabile". >> > > Già, ma in questo caso l'uguaglianza è data dal contenuto (usi set.__eq__). > Quindi puoi avere due oggetti uguali ma con hash diverso, che è contrario > alla > semantica che dict si aspetta dall'hash (due oggetti uguali devono avere lo > stesso hash). > > Quindi non sono sicuro che tu abbia risolto il tuo problema, a meno che non > implementi anche: > > def __eq__(self, other): > return self.ID == other.ID > > (e tanto vale usare la funzione id() a questo punto). > Già, che stolto. Hai probabilmente scongiurato anticipatamente una mia altra disperata richiesta ... Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Consiglio su utilizzo di variabili globali
On Sun, May 4, 2008 at 4:14 PM, enrico franchi <[EMAIL PROTECTED]> wrote: > On Sat, May 3, 2008 at 4:33 PM, Mr. SpOOn <[EMAIL PROTECTED]> wrote: > > > In effetti avevo pensato proprio a una cosa simile. Come mai è meglio > > lasciarli perdere? > > Perchè non fanno assolutamente nulla. Se devi scrivere una funzione > per fare un assegnamento, scrivi l'assegnamento e basta. > Quella dei setter/getter banali è una mania dei Javisti che sarebbe > bene non fare proliferare ulteriormente. E' vero. Non per niente sono stato abituato a programmare in Java -_- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Consiglio su utilizzo di variabili globali
> Ma una variabile di modulo non puoi sostituirla con una proprietà, quindi io > mi terrei stretto il getter. Ci sono un sacco di situazioni in cui fa comodo: > > - inizializzare il valore al suo primo accesso > - consentire la lettura ma non la scrittura > - serializzare gli accessi > > ...eccetera. Si, ma tutte queste cose mi fanno pensare che sia più appropriato un refactoring del tutto. Tipicamente questa qui IMHO si sta candidando per finire dentro una classe che gestisce lei il tutto. Direi che ancora una volta il pattern Borg è proprio il candidato ideale. -- -enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dubbi su hash e set
2008/5/4 Pietro Battiston <[EMAIL PROTECTED]>: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > enrico franchi ha scritto: > > > On Fri, May 2, 2008 at 8:46 PM, Pietro Battiston <[EMAIL PROTECTED]> wrote: > > > >> Ora, la mia coscienza sporca mi suggerisce che forse quando ho > >> sovrascritto __hash__ ho fatto più di quanto dovrebbe fare uno che di > >> internal Python non ne sa abbastanza, e che le hash di tutti gli > >> oggetti che conosco sono (solitamente) univoche. Ma... > > > > Non è questione di internals. E' questione di algoritmi. Devi definire > > una funzione (quasi) univoca sugli oggetti che a te interessano. > > La proprietà è che se hash(x) == hash(y) per te x e y devono essere > > uguali e che possibilmente se devono essere diversi non abbiano lo > > stesso hash (che vuole dire "è estremamente poco probabile che..."). > > OK, allora i miei scrupoli erano ingiustificati e stavo effettivamente > agendo "legalmente". Quindi?! > > > >> "not necessarily true" non significa che dovrebbe alla fine fregarsene > >> se in un insieme due elementi distinti (e peraltro identici in tutto > >> tranne l'allocazione di memoria) hanno la stessa hash?! > > > > Dice chiaramente: due valori con lo stesso valore hanno anche lo stesso > hash, > > due valori con diverso hash potrebbero avere lo stesso valore (o anche > > no). E' frequente: per esempio se crei una classe "vuota" tutte le sue > > istanze avranno lo stesso hash (se la prova non mi inganna). > > In realtà qualche osservazione empirica mi fa pensare che in caso di > __hash__ non definita, hash(x) = id(x). Comunque ho afferrato il concetto. Si, hai ragione tu, presente quando uno pensa una cosa e ne scrive un'altra (e ho pure fatto l'esperimento). Vabbè. Comunque non è che __hash__ non è definita, poichè viene ereditata da object. Ed in effetti id è un buon candidato per essere un valore di hash di default, visto e considerato che: 1. non cambia durante la vita dell'oggetto 2. è sempre univoco. Peccato che sia 'troppo' univoco. Due oggetti sensatamente uguali risultano con hash diverso, che non è quello che vuoi per usarli come chiavi di un dizionario. Comunque confermo quello che ha scritto altrove Daniele: devi definire anche __eq__ oppure __cmp__. Quello risolverà i tuoi problemi. Stilisticamente aggiungo: trovo spesso e volentieri poco saggio ereditare da classi built-in che non necessariamente sono state pensate per questo scopo. Hai spesso sorprese di vario genere e devi stare venti volte più attento che usando semplice contenimento. class my_list(list): pass s1 = my_list() s2 = my_list() s3 = s1 + s2 print "s3:", type(s3) -> list Per dire. Questa è una cosa difficile da prevedere e può romperti di brutto il codice. Con set pare essere più robusto ma "è culo". Io fossi in te penserei il tutto in termini di contenimento, scrivi pochissimo codice in più, ma hai molto più controllo e meno sorprese. -- -enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dubbi su hash e set
enrico franchi ha scritto: > class my_list(list): > pass > > > s1 = my_list() > s2 = my_list() > s3 = s1 + s2 > > print "s3:", type(s3) > -> list > > Per dire. Questa è una cosa difficile da prevedere e può romperti di > brutto il codice. Con set pare essere più robusto ma "è culo". Io > fossi in te penserei il tutto in termini di contenimento, ovvero?! Intendi "classe non derivata che ha come attributo un set"? In effetti mi farei meno paranoie sulla classe, ma mi dovrei fare più paranoie in giro per il programma in cui questa classe è usata, per cui preferisco spendere un pochettino di tempo in più a controllare che tutto sia OK (una volta, ovviamente, che so come tutto dovrebbe funzionare). (O intendi qualcos'altro? Io per ora del tipo "set" sto usando update, remove, add, metodi che non vorrei dover ridefinire) Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Consiglio su utilizzo di variabili globali
Il giorno 04/mag/08, alle ore 16:14, enrico franchi ha scritto: > On Sat, May 3, 2008 at 4:33 PM, Mr. SpOOn <[EMAIL PROTECTED]> > wrote: > >> In effetti avevo pensato proprio a una cosa simile. Come mai è >> meglio >> lasciarli perdere? > > Perchè non fanno assolutamente nulla. Se devi scrivere una funzione > per fare un assegnamento, scrivi l'assegnamento e basta. > Quella dei setter/getter banali è una mania dei Javisti che sarebbe > bene non fare proliferare ulteriormente. In java tipicamente HA senso, visto che rifattorizzare ha un costo immensamente piu'alto che in linguaggi agili...poi con le "simpaticissime" regole di visibilita' e i minimo 5 livelli di gerarchia di classi tipici, tantovale far fare il proprio mestiere a eclipse/netbeans/quellochee' ;-) In python naturalmente ha ben poco senso, vista la presenza delle property e vista la facilita' di refactoring... -- Antonio Valente ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dubbi su hash e set
On Sun, May 4, 2008 at 7:20 PM, Pietro Battiston <[EMAIL PROTECTED]> wrote: > (O intendi qualcos'altro? Io per ora del tipo "set" sto usando update, > remove, add, metodi che non vorrei dover ridefinire) E non ridefinirli. Delegali. -- -enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
