[Python] Why Go is not good

[Enrico Bianchi]

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