[Python] Dubbi su hash e set

[Pietro Battiston]

enrico franchi ha scritto:
> 2008/5/5 Pietro Battiston <toobaz a email.it>:
>   
>>  Pazienza per il mini-corso, ma un indizio del perché ti sia così chiaro
>>  che la mia relazione è del tipo has-a?!
>>  A me sembra di avere "deciso", più che "verificato", che la relazione è
>>  del tipo is-a, perché mi sta più comodo così.
>>     
>
> Scusa, ma non capisco per quale motivo un "vertice" dovrebbe *essere*
> un insieme.
>   

Perché un vertice - nella mia applicazione - è prima di tutto la
giunzione di diversi lati. Voglio potere ad esempio congiungere (union,
o update) due vertici, ovviamente non voglio lati doppioni in uno stesso
vertice.

Poi ha il campo ID che serve sostanzialmente a distinguere i vertici e
togliere di mezzo quelli ormai inutili.

Peraltro l'assunzione "due vertici sono uguali solo se //contengono le
stesse cose//" rimane vera (tranne che per i vertici ormai vuoti).

> Non mi è nemmeno chiaro il perchè dovrebbe essere implementato in
> termini di insieme,
> ma questo suppongo dipenda che non ho presente il tuo problema specifico.
>   

Maneggio dei particolari grafi (sviluppi piani di poliedri e cose
simili). So che ci sono librerie fantasmagoriche per i grafi, ma avrei
comunque dovuto aggiungere un sacco di caratteristiche (ad esempio, le
facce e la loro orientazione), per cui ho preferito partire da zero.

Ovviamente di un vertice mi interessano i lati che ci arrivano, mentre
dell'ordine me ne frego abbastanza (in realtà questa è più che altro una
scelta, perché semplicemente l'ordine non mi interessa per quel che
dovrò poi farci).

>>  Sto "chiedendo guai" nel senso che non sapevo proprio quali erano i
>>  requisiti per essere "set-compliant", ma ora che so come evitare danni
>>  con gli unici due metodi che dovevo sovrascrivere...
>>     
>
> Hai guardato il mio codice di esempio?
>
> Il problema è che devi avere idea *precisa* sul funzionamento della
> classe da cui erediti, di *tutto*, anche di quello che non usi.
> Altrimenti puoi trovare bachi inaspettati.
>   

Sì, sul principio generale hai perfettamente ragione. La verità è che se
mai deciderò che val la pena pubblicare quel che sto facendo, dovrò
ovviamente essere certo che ogni metodo che la mia classe ha (o eredita)
sia consistente, e in quel caso viva il duck typing, ma finché è una
roba mia mi fa estremamente comodo, spippolando con ipython, avere a
portata di mano tutto e subito per sperimentare, e magari fare anche
cose non consistenti (per debug, mi sono addirittura //scritto// metodi
che rendono il tutto non consistente). E che comunque lavorare in modo
"pulito" non avrebbe risolto il problema per cui avevo scritto in lista.

>>  In cui parla proprio e solo di eredità... ?! E dice ovviamente di
>>  evitare la cavolata che facevo quando ho scritto la prima mail, ma che
>>  ora mi sembra di aver risolto... ma di per sé, il principio "non fare
>>  arrabbiare le classi da cui erediti" mi sembra anche piuttosto scontato...
>>     
>
> La cosa che ti dice (leggendolo) è anche che devi stare *molto*
> attento a rispettare i contratti impliciti delle tue classi padre.
> Per cui, di fatto, ti conviene farlo solo con *moltissima* attenzione.
> Il che vuole dire, di base, non farlo.
>   

Certo, per qualcosa che dovessi rilasciare al pubblico non avrei dubbi.

Per quel che riguarda me, preferisco che le funzioni "dalla coerenza
incerta" ci siano piuttosto che siano nascoste.

>>  Qui mi sa che mi mancano un po' di basi per capire... in Python non è
>>  //tutto// open (a parte casomai la sovrascrittura dei metodi di tipi e
>>  classi builtin, ma mi sembra il minimo)?! Insomma, da quel pochissimo
>>  che so di Java, e forse in C++, so che ci sono classi pubbliche e
>>  private... in Python capisco che ci siano "calde raccomandazioni" per
>>  chi usa un certo modulo, ma alla fine decidere "cosa è open" si riflette
>>  tutt'al più nella documentazione, no?!
>>     
>
> No. E' una questione "filosofica". Cioè è vero che in Python posso
> prendere una classe e patcharla a runtime,
> ma qui il discorso è soprattutto evolutivo.
>   
> Cioè tu scrivi un modulo/classe/whatever. Se lo scrivi bene, quel
> modulo sarà facilmente estendibile
> in un secondo momento (quando le esigenze cambieranno) e questo
> avverrà tipicamente senza mettere
> troppo mano al codice esistente. Questa è una volgarizzazione
> terribile, ma dovrebbe rendere bene la faccenda.
>   

Sì, abbastanza. Forse la cosa non mi tange troppo solo perché non ho mai
partecipato all'"evoluzione" di niente in Python, finora quello che ho
scritto l'ho scritto sempre da solo, e tutti i miei moduli erano di
"alto livello" (non nel senso di qualità ma di specializzazione).

Pietro