On 07/13/2015 11:55 AM, enrico franchi wrote:
Il problema con l'overloading e' che rende un sacco di cose
drammaticamente piu' complicate: in presenza dello stesso caso che
menzioni (ovvero che non sai quale tipo sia una variabile) vuole dire
che effettivamente il tuo codice compilera', ma tu non avrai idea di
cosa faccia.
Mmm... non sono del tutto convinto, ovvero se io implemento Sum(int,
int) e Sum(float, float), io so che posso avere o un int o un float e
comportarmi di conseguenza
Se non sai quale e' il tipo della variabile, vuole dire che non sai
quale variante del metodo verra' chiamata. E quindi di fatto non sai
che codice stai eseguendo. Ecco che un'innocua seccatura in assenza di
overloading e' diventata una possibile fonte di bachi.
Mmm... In altre parole, stai dicendo che Python, in quanto (di solito)
non sai il tipo della variabile masolo il suo contenuto, e` altamente
problematico ;)
Questo e' un problema completamente *non* relativo a quello di la sopra.
Si, lo so, ma mi divertiva postarlo ;)
non riesco a vedere come un problema il fatto che se dereferenzi
puntatori senza fare check sei nella guazza.
Senza offesa, ma da come rispondi sembrerebbe che ti soffermi piu` sul
codice che sul concetto che volevo esprimere. Quello che interessa a me
e` fare il catch del panic, in quanto, ad esempio, potrei voler fare in
modo che l'applicazione non debba terminare assolutamente la sua
esecuzione se non tramite intervento manuale. La soluzione, come dico in
seguito (e come ho scoperto proprio grazie a questo thread) e` usando
recover() in una deferred function, che di per se non e` anche una
cattiva soluzione, anche se limitata dalla gestione dei defer in Go
(ovvero a cascata non appena la funzione viene eseguita completamente)
E il modo in cui lo risolvi in Python e', appunto, sbagliato a mio
avviso. In primo luogo il catch all except e' qualcosa che viene
sconsigliato da lungo tempo.
Posso essere d'accordo, ma secondo me lo sconsigliare una pratica del
genere e` difettata dalle varie casistiche. Vedi ad esempio il caso di
un'applicazione che non deve morire mai
a = may_return_null(...)
if a is not None:
f(a, ...)
Bruttino, non tanto perche` non mi piace, ma per com'e` scritto :)
La sintassi
if a:
f(a,...)
E` molto piu` elegante (si, e` una pulce che non serve a molto) :)
Fanno sempre e solo stack unwind, non danno controllo al programmatore.
Mmm... continuo a non capire... Un esempio (o della documentazione)?
Come dicevo... quello non e' Go idiomatico a mio avviso.
Anche qua, mi sembra che tu abbia dato piu` peso al codice che ho usato
come esempio piuttosto che al concetto che volevo esprimere.
Personalmente ritengo che un try/except sia piu` elegante rispetto al
dover fare il check per ogni error che ti viene restituito. Quello che
intendo e` che, ad esempio, le operazioni di apertura, scrittura e
chiusura di un file in Go devono essere gestite una per una, mentre in
Python le posso gestire tutte nello stesso try/except che,
personalmente, ritengo piu` sensato
Ancora peggio quando hai codice "lineare" del tipo fai una serie di
operazioni una in fila all'altra. E hai errori vari che possono
arrivare da ognuna di queste (possibilmente con un set di eccezioni
non disgiunto per le varie chiamate).
Boh, a pensarci mi sembrano abbastanza semplici e pulite da gestire...
Enrico
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
