[Python] Dubbi su hash e set

[Pietro Battiston]

enrico franchi ha scritto:
> 2008/5/6 Pietro Battiston <toobaz a email.it>:
>
>   
>>  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.
>>     
>
> Quindi un vertice è *implementato* in termini di "insieme". Per
> esempio tutte le operazioni  che puoi fare fra due insiemi le puoi
> anche fare tra due vertici?

Il fatto è che lo scoprirò solo vivendo... e ogni tanto scopro
effettivamente una nuova operazione che mi fa comodo.

> E fra un insieme e un vertice? L'insieme
> vuoto è un concetto perfettamente sensato.
> Il "vertice vuoto"? E il
> vertice di un solo lato? E' un insieme normale, ma come vertice non ha
> senso.
>   


Forse (ma solo forse) c'è un equivoco: considero "vertex" una classe
"interna", da non istanziare esplicitamente se non si sta proprio
modificando il modulo (dovrei chiamarla __vertex__? è sbagliato
considerare certe classi interne nel senso che chi le usa deve sapere
quello che fa, ovvero che verranno usate solo in certe funzioni che
"sanno quello che fanno"? se sì, come si fa a sopravvivere?!)


>>  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.
>>     
>
> Non mi sembra un discorso che si regge: non ti costa nulla seguire dei consigli.
>   

Magari un giorno mi sveglio e dico "OK, ora pubblico questo codice,
trasformiamo l'ereditarietà in contenimento e/o aggiungiamo tonnellate
di NotImplemented". Ma per ora ogni giorno scopro cose a cui non avevo
pensato, ed è inutile illudermi di poter scegliere a priori quali
funzioni mi faranno comodo; trovo i sistemi migliori sperimentando, e
per questo (ma anche solo per debug!) avere a portata di mano anche
funzioni eventualmente incoerenti mi fa comodo.

Certo, non è che me ne frego di come si fa le cose per bene, e tutto
quello che dici è sacrosanto e mi interessa; soltanto, capita di
scrivere programmi per risolvere un problema noto in modo noto o
comunque genericamente prestabilito, ma capita anche di fare programmi
ricercando attivamente i modi migliori di approcciare un problema e
anche solo di formularlo. Da questo punto di vista, ho sempre apprezzato
il fatto che ipython sia una vera e propria "calcolatrice".

> Oltretutto progettare bene le gerarchie di classi non è una cosa
> banale, non è una cosa che ti insegnano in università,

... e tantomeno a me che studio matematica...

> ma è una cosa
> che impari con l'esperienza. Se non dai peso al design perchè "tanto è
> per te", quando dovrai farlo per gli altri, semplicemente non avrai
> accumulato le skills necessarie. Se invece fin da principio hai
> provato a progettare bene le cose, quando dovrai farlo anche per gli
> altri, saprai come farlo.
>
> Fra le altre varie cose, a volte anche persone decisamente esperte
> sbagliano. Solo in genere se ne accorgono un po' prima e talvolta non
> è troppo tardi.
>   

A dire il vero, questo programma che sto scrivendo io lo sto riscrivendo
da zero. Con la prima versione avevo completamente toppato l'approccio
al problema. Quindi so cosa intendi. Ma di per sé la questione
"contenimento vs. ereditarietà" mi sembra molto più "superficiale", nel
senso che è importante ma il giorno che vorrò cambiare si tratterà
veramente solo di cambiare __init__ ed aggiungere 4-5 metodi
semplicissimi...
... e per ora mi trovo meglio così...

Pietro