Re: [Python] Why Go is not good

[enrico franchi]

2015-07-18 12:19 GMT+01:00 Enrico Bianchi :

> C'e` anche questo da tenere in considerazione:
>
> https://docs.python.org/3/library/stdtypes.html#truth-value-testing
>

Si, di quello si sta parlando, appunto.




-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Enrico Bianchi]

On 07/17/2015 03:13 PM, enrico franchi wrote:

In realta' il primo e' anche il piu' broken. Dalla PEP8:


C'e` anche questo da tenere in considerazione:

https://docs.python.org/3/library/stdtypes.html#truth-value-testing

Enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[enrico franchi]

2015-07-17 14:33 GMT+01:00 Davide Muzzarelli :

Yes:   if greeting:
No:if greeting == True:

Nel suggerimento la differenza tra "Yes" e "No" è solo sintassi.
>

No. E' semantica. Nel primo caso stai di fatto andando a chiamare
greeting.__nonzero__ se presente, se no greeting.__len__ e altrimenti e'
semplicemente vero. Nel secondo invece stai andando a chiamare
greeting.__eq__ (oppure greeting.__neq__ oppure greeting.__cmp__) oppure
stai andando a confrontare gli id degli oggetti.

Tipicamente quei due frammenti non sono sintatticamente diversi: sono
filosoficamente diversi. Sono pure ortogonali. Il caso in cui collassano e'
essenzialmente se greeting e' un booleano o un'intero (o qualcosa che si
comporta come tale).

Il terzo caso invece non è affatto sintassi e lo usi quando vuoi essere
> sicuro anche del tipo.
>

Il terzo, come i primi due, non e' solo sintassi e *non* lo usi. E se lo
usi mettici dei bei commenti a spiegare perche' lo usi. Siccome nel 99.9%
dei casi e' un bug, e' molto facile che il primo che ripassa sul codice te
lo sega via. Per cui se c'era un buon motivo, e' bene specificarlo.

Tra l'altro in Python quando cominci a fare check espliciti sui tipi il
codice puzzicchia. Ci sono motivi per farlo e niente da dire... ma sono
*moolto* rari.

Diventa worse se usi l'is quando non serve, ovvero nella maggioranza dei
> casi.
>

Praticamente nella totalita'. Comunque sia == che is in quel caso sono
moolto sospetti.



-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Davide Muzzarelli]

Il 17/07/2015 15:13, enrico franchi ha scritto:

In realta' il primo e' anche il piu' broken. Dalla PEP8:

  *

Don't compare boolean values to True or False using == .

Yes:   if greeting:
No:if greeting == True:
Worse: if greeting is True:


Nel suggerimento la differenza tra "Yes" e "No" è solo sintassi. Il 
terzo caso invece non è affatto sintassi e lo usi quando vuoi essere 
sicuro anche del tipo.


Diventa worse se usi l'is quando non serve, ovvero nella maggioranza dei 
casi.


Può darsi che io abbia intuito male cosa volesse fare Carlos.

Byez,
Davide Muzzarelli
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[enrico franchi]

2015-07-17 14:01 GMT+01:00 Davide Muzzarelli :

> Il motivo è che il primo if controlla anche il tipo mentre gli altri due
> no.
>

In realta' il primo e' anche il piu' broken. Dalla PEP8:


   -

   Don't compare boolean values to True or False using == .

   Yes:   if greeting:
   No:if greeting == True:
   Worse: if greeting is True:









-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Carlos Catucci]

2015-07-17 15:10 GMT+02:00 enrico franchi :

> si il codice fa cacare, e' solo un esempio per mostrare come in Python hai
> nell'if qualcosa che non e' un booleano (ma che viene valutato in contesto
> booleano).


Ok mai io quello intendevo, la valutazione e' sempre boolean. Se poi gli
passo un oggetto not bool sono io che ho fatto la frittata.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[enrico franchi]

2015-07-17 13:50 GMT+01:00 Carlos Catucci :

> Sara' che preferisco avere codice leggibile e tranquillo.
>

E non idiomatico. Il Python idiomatico presuppone che tu spesso e
volentieri hai nella guardia dell'if (o del while) cose che *non* sono
booleani.
Non farlo ti costringe a scrivere pessimo Python (e a dovere scrivere
soluzioni terribilmente piu' complicate).


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Carlos Catucci]

2015-07-17 15:01 GMT+02:00 Davide Muzzarelli :

> Il motivo è che il primo if controlla anche il tipo mentre gli altri due
> no.


Mi sero speigato male
se io scrivo

a = True
if a:

  do something

puo' andare bene, e comunque mi piace poco lo stesso, preferirei comunque
un'esplicito

a = True
if a == True:

  do something

Carlos



-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[enrico franchi]

2015-07-17 13:38 GMT+01:00 Carlos Catucci :

> Adesso mi spieghi questa, a me povero 'gnurant. Come puoi avere un if
> senza espressioni booleane? Al massimo sono piu' espressioni combinate tra
> loro con operatori logici ma sempre booelane sono.


def recursive_print_list(lst):
if lst:
   print lst[0]
   recursive_print_list(lst[1:])

si il codice fa cacare, e' solo un esempio per mostrare come in Python hai
nell'if qualcosa che non e' un booleano (ma che viene valutato in contesto
booleano).


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[enrico franchi]

2015-07-16 23:53 GMT+01:00 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
>

Allora, in Go, si, perche' non hai type cohercion. In altri linguaggi? Devi
certamente ricordarti tutte le conversioni implicite. Per dire, in molti
linguaggi un long chiamerebbe la versione per float invece che quella per
int. Per dire... super intuitivo ;) Ricordati che i bachi hanno la tendenza
a rendersi manifesti alle 2 di notte quando a guardare il problema c'e'
tipicamente qualcuno che non e' l'ingegnere che ha scritto il codice.

E' un peccato che tu abbia tagliato il mio altro esempio che mostrava in
modo completamente evidente quale sia il problema grosso (e che la mancanza
di conversioni automatiche non e' sufficiente ad evitarlo). Se lo avessi
studiato un pochetto ti saresti chiarito quale e' il punto.


>  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 ;)


Per assurdo molto meno. Almeno non ci sono dubbi su quale sia il codice
della funzione che viene chiamato. Poi c'e' sempre il problema di quale sia
il codice che la funzione che hai chiamato chiama a sua volta, ma quello fa
parte del concetto di polimorfismo e tipicamente non vuoi farne a meno. E'
un male quasi necessario.



>  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)


Eh, ma se mostri codice per rappresentare il problema, ma il codice che
mostri non rappresenta il problema io posso solo parlare del codice in
se... la sfera di cristallo non mi funziona troppo bene. :)

Comunque, dipende come e' concepito il sistema. Ci sono casi in cui vuoi
catturare un'eccezione piuttosto esterna. Tipicamente posso pensare ad un
webserver essenzialmente stateless: fallisci la richiesta, tiri un 5xx e
vai avanti. Essendo stateless, non hai il problema che il panic sia un
sintomo di memoria corrotta. E se il sistema e' messo su da persone
normodotate avrai un quache allarme se il rate di 5xx e' troppo alto (che
indicherebbe a sua volta che il sistema e' compromesso e che bisogna
intervenire). Quindi anche in questo caso devi comunque avere qualche tipo
di supporto a livello di sistema/operations.

Su un sistema stateful in molti casi preferisco abbattere l'applicazione e
non pensarci due volte. Tanto (sempre siccome parliamo di individui
normodotati) il sistema avra' qualche tipo di ridondanza e questo non e' un
problema. E ci sara' qualche tipo di nanny che ritira su il tutto
(possibilmente partendo da uno stato non corrotto). Se ancora una volta
l'applicazione va giu' troppe volte in poco tempo vuole dire che c'e' un
problema, ci sara' un allarme e qualcuno dovra' correre a guardarci. Oppure
se abbiamo abbastanza capacity (che so... siamo in N+K) ci si guarda il
giorno dopo e tanti saluti. Nota, questo approccio funziona anche (e come
sempre meglio) in un sistema stateless: semplicemente se hai stato
catturare un'eccezione, loggare e andare avanti puo' volere dire che
quell'istanza da quel momento in poi serve merda, hai un gray failure ed e'
molto peggio: meglio abbattere tutto e tanti saluti.

Nel caso specifico di Go, ritirare su un'applicazione e' generalmente una
cosa molto veloce. *E* i panic non dovrebbero segnalare condizioni
"normali". Quindi e' assolutamente concepibile pulire tutto e fare morire e
saluti.


> 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


Salvo che nel tuo caso l'applicazione moriva comunque. Tra l'altro mi
aspetto che tu conosca la differenza fra except: ed ex

Re: [Python] Why Go is not good

[Davide Muzzarelli]

Il 17/07/2015 14:50, Carlos Catucci ha scritto:

non avrebbe senso. Potrei farlo solo se avessi un

a = True o a = False


Forse intendi:

if a is True:
...

altrimenti è esattamente come se facessi:

if a:
...

proprio perché il seguente if risulterà vero:

a = 1
if a == True:
...

Il motivo è che il primo if controlla anche il tipo mentre gli altri due no.

Byez,
Davide Muzzarelli
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Carlos Catucci]

2015-07-17 14:46 GMT+02:00 Davide Muzzarelli :

> b := nil // Sarebbe un None in Python
> if b { // Errore!
> ...
> }
>
> e nemmeno:
>
> c := 1
> if c { // Errore!
> ...
> }
>

Ah ecco, sara' che io certe brutte abitudini non le ho mai avute. Per me
True e False sono True e False, se ho

a = 1

non farei mai

if a:

pass

non avrebbe senso. Potrei farlo solo se avessi un

a = True o a = False


Sara' che preferisco avere codice leggibile e tranquillo.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Davide Muzzarelli]

Il 17/07/2015 14:38, Carlos Catucci ha scritto:

Adesso mi spieghi questa, a me povero 'gnurant. Come puoi avere un if
senza espressioni booleane? Al massimo sono piu' espressioni combinate
tra loro con operatori logici ma sempre booelane sono.


Intende che puoi fare:

a := true // Variabile booleana
if a {
...
}

e che invece non puoi fare:

b := nil // Sarebbe un None in Python
if b { // Errore!
...
}

e nemmeno:

c := 1
if c { // Errore!
...
}


Byez,
Davide Muzzarelli
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Carlos Catucci]

2015-07-17 14:28 GMT+02:00 Manlio Perillo :

> In Go per evitare problemi del genere hanno deciso che l'istruzione `if`
> accetta solo espressioni booleane.


Adesso mi spieghi questa, a me povero 'gnurant. Come puoi avere un if senza
espressioni booleane? Al massimo sono piu' espressioni combinate tra loro
con operatori logici ma sempre booelane sono.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Manlio Perillo]

2015-07-17 0:53 GMT+02:00 Enrico Bianchi :

> On 07/13/2015 11:55 AM, enrico franchi wrote:
>
>> > [...]

>
>  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) :)


Io ti consiglio di lasciare `a is not None`.
`if a` può significare troppe cose, specialmente in Python, e rischi di
ritrovarti con un comportamento inaspettato.

In Go per evitare problemi del genere hanno deciso che l'istruzione `if`
accetta solo espressioni booleane.


>
>  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.


http://blog.golang.org/errors-are-values



> 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
>
>
Fino a quando non devi gestire l'errore.
A molti le eccezioni piacciono perchè ti fanno "dimenticare" che c'è stato
un errore.

Il codice è "bello", ma quando devi gestire gli errori poi le cose iniziano
ad andare in modo diverso.
E la gente inizia a fare:

except Exception:
#  print traceback

se non di peggio.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [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
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[enrico franchi]

2015-07-13 14:56 GMT+01:00 Manlio Perillo :

> In Python qualche volta ho dovuto scrivere una funzione inversa a quella
> che ho postato per Go, per gestire il caso in cui
> un errore restituito da una funzione in os non era un caso eccezionale.
>

Diciamo di continuo. O meglio, non e' che scrivo la funzione di continuo
(visto che tipicamente finisce in librerie condivise)...
Ma per dire... quando usi mkdirs, ENOENT non e' un vero errore. Idem quando
cerchi di implementare scritture atomiche.
E cosi' via...; tutta quella parte finisce sempre per guardare l'errno
dell'eccezione e vedere cosa fare.


> Personalmente preferisco l'approccio di Go.
>

+1


> A parte alcuni casi, come l'accesso ad un elemento di un array/slice e
> allocazione della memoria, lo posso decidere
> solo io se un errore è eccezionale o meno, in base al contesto.
>

Yeah.



-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Manlio Perillo]

2015-07-13 14:49 GMT+02:00 enrico franchi :

>
> 2015-07-13 12:01 GMT+01:00 Manlio Perillo :
>
>> solo se devi creare un file durante l'inizializzazione di un package
>> (come ad esempio con text/template e html/template).
>>
>
> Certo. Ma in generale per me il fatto che un file non possa essere creato
> non e' un panic.
>


Dici benissimo quando aggiungi "in generale".

In Python qualche volta ho dovuto scrivere una funzione inversa a quella
che ho postato per Go, per gestire il caso in cui
un errore restituito da una funzione in os non era un caso eccezionale.

Personalmente preferisco l'approccio di Go.
A parte alcuni casi, come l'accesso ad un elemento di un array/slice e
allocazione della memoria, lo posso decidere
solo io se un errore è eccezionale o meno, in base al contesto.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[enrico franchi]

2015-07-13 12:01 GMT+01:00 Manlio Perillo :

> solo se devi creare un file durante l'inizializzazione di un package (come
> ad esempio con text/template e html/template).
>

Certo. Ma in generale per me il fatto che un file non possa essere creato
non e' un panic. Certo, alcuni casi sono panic, ma dipende molto dal
dominio applicativo.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Manlio Perillo]

2015-07-13 11:55 GMT+02:00 enrico franchi :

>
> Dipende dal concetto di snello che hai Per esempio, se per creare un file,
>> devo fare questo:
>>
>> file, err := os.Create(filename)
>> if err != nil {
>>   panic(err)
>> }
>> defer file.Close()
>>
>

> Come dicevo... quello non e' Go idiomatico a mio avviso.
>

Il modo idiomatico è di scrivere un wrapper tipo

func MustCreate(filename string) {
file, err := os.Create(filename)
if err != nil {
panic(err)
}

return file
}

solo se devi creare un file durante l'inizializzazione di un package (come
ad esempio con text/template e html/template).

> [...]


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[enrico franchi]

2015-07-11 16:03 GMT+01:00 Enrico Bianchi :

> On 07/03/2015 03:36 PM, enrico franchi wrote:
>
>>  Parli di override o di overload?
>>
> Oddio, confondo sempre i termini...
>

Ok, a te interessa fare overloading.


> Quello che mi interessava fare era semplicemente questo:
>
> func Sum(a, b int) int {
>   return a + b
> }
>
> func Sum(a, b float) float {
>   return a + b
> }
>
> Certo, posso usare anche SumInt e SumFloat, ma diventa molto piu`
> complesso, ovvero potrei avere un caso in cui non so il tipo di variabile e
> prima me lo devo andare a cercare (a meno di non fare evidenti cast di
> variabili).


Si, capisco. Ma explicit is better than implicit. In primo luogo, a me
verrebbe da dire che non e' del tutto normale non sapere il tipo statico di
una variabile e volerci fare sopra cose. Tipicamente finisce che qualcosa
non funziona.

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. 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.

Ma in generale, tutte le volte che ho avuto a che fare con overloading,
avrei voluto *non* averlo. Certo, l'idea di SumInt e SumFloat da davvero
fastidio e fa brutto. Poi quando uno realizza quello che implica, dice
toglietelo. *Specie* ma non limitatamente alla combo overloading + type
conversion implicite. Troppe regole da tenere a mente, troppo facile fare
cazzate.

Ci sono chiari esempi di API design piuttosto sensati che in presenza di
overloading diventano relativamente complessi da gestire. Il primo che mi
viene in mente e' quello di slf4j (facade di logging su Java). Questo
esempio non ha nemmeno il problema dell'interazione con le type conversion
e similia.

- error(String, Object)
- error(String, Object, Object)
- error(String, Object...)
- error(String, Throwable)

In pratica quando gli passi un singolo throwable fa una cosa [case (d)],
quando passi un singolo object [case (a)] ne fa un'altra (che e' un caso
speciale di quello che succede quando gliene passi 2 [case (b)] o N
[case(c)]). E' veramente facile senza pensarci troppo prendere una chiamata
tipo:

logger.error("...", t);

e farla diventare, che so...

logger.error("...: {}", t, o);

e non accorgersi che la semantica e' cambiata parecchio (in particolare
quello che accade con lo stack-trace).



> Per inciso, ricordo un thread su di un gruppo Facebook in cui si criticava
> specificatamente la mancanza di questa caratteristica (e in cui era uscita
> anche questa cosa simpatica: http://play.golang.org/p/Isoo0CcAvr )


Questo e' un problema completamente *non* relativo a quello di la sopra. In
effetti trattano parti di linguaggio completamente distinti. Potrsti avere
overloading e avere ancora quel problema sopra menzionato.


>
>
>  Credo che tu non abbia chiara la gestione degli errori in Go.
>>
> Guarda, faccio prima a farti vedere cosa intendo: prendiamo questo caso:
>
> package main
>
> import (
>   "fmt"
> )
>
> func Sum(a int, b *int) int {
> return a + *b;
> }
>
> func main() {
> var first int
> var second *int
>
> first = 1
> second = nil
> fmt.Println(Sum(first, second))
> }
>
> Questo codice genera, ovviamente, un runtime error in quanto passo un
> puntatore nil come argomento della somma. Ora, per gestire questa
> situazione, posso sicuramente fare un check che le variabili siano
> valorizzate, ma questo non mi protegge da altri "imprevisti". Per capirci,
> una situazione del genere in Python la gestirei cosi`:
>
> def sum(a, b):
> return a + b
>
> if __name__ == "__main__":
> try:
> print(sum(1, None))
> except:
> print("Argh!")
>
> (il che potrebbe essere deprecabile in alcuni contesti, mentre in altri,
> e.g. per gestire la morte prematura delle connessioni da parte di un
> client, potrebbe essere una facility non indifferente)


Scusa, non capisco. Mi fai vedere un pezzo di codice ... pezzo di codice
che ha chiaramente un baco (indipendente da Go). Cioe', quel codice non
dovrebbe essere scritto in quella maniera (e non dovrebbe essere utilizzato
in quella maniera). Tra l'altro, per come funziona Go, non ci sono estremi
buoni motivi per scriverlo in quella maniera... ora, capisco che sia un
esempio... ma non riesco a vedere come un problema il fatto che se
dereferenzi puntatori senza fare check sei nella guazza.

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. E, per il resto, si espone un'altro problema di Python sugli
esempietti piccoli.

In Java una funzione come sum(Integer a, Integer b) la av

Re: [Python] Why Go is not good

[enrico franchi]

2015-07-11 16:09 GMT+01:00 Enrico Bianchi :

> Cercando mentre stavo scrivendo questa email mi sono imbattuto in proprio
> in quello che cercavo, ovvero nel builtin recover(), che non fa altro che
> fare il catch di panic(). In altre parole, l'esempio da me riportato,
> potrebbe diventare qualcosa del genere


E' proprio meglio non pensare di usare panic dove useresti un'eccezione.
Usa panic per dire: hey, qui e' successo qualcosa che davvero non sarebbe
dovuto succedere: per quanto mi riguarda mandiamo tutto a monte e
andiamocene a casa... se poi qualcuno ha idee (o vuole pulire prima di
andarcene) facciamolo.

Per dire, il caso in cui non trovi il file da aprire ( o non hai i permessi
) e' una cosa *normale*. Non e' un eccezione per Go. Il fatto che mi hai
sparato un puntatore vuoto e io dovrei prelevare un valore da quello e'
piu' simile ad un panic, dal mio punto di vista.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Enrico Bianchi]

On 07/11/2015 05:09 PM, Enrico Bianchi wrote:
Cercando mentre stavo scrivendo questa email mi sono imbattuto in 
proprio in quello che cercavo

E mentre stavo scrivendo questo sono entrato in modalita` ricorsiva... -_-

Enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Enrico Bianchi]

On 07/03/2015 03:04 PM, enrico franchi wrote:
Scusa, io quell'articolo non lo ho capito. Nel senso che dovrebbe 
parlare delle performance di Go (apparentemente da questo thread), ma 
in realta' si mette a spiegare roba sui cripto-sistemi.
In effetti quell'articolo parla specificatamente di TLS, e mi trova 
d'accordo piu` che altro perche` ci ho sbattuto il grugno direttamente. 
Ma il concetto rimane quello, personalmente mi verrebbe da dire che ora 
dovrebbero entrare nella fase due, ovvero estendere ed ottimizzare la 
stdlib (che il compilatore sia veloce ed ottimizzato e` cosa buona e 
giusta, ma se dietro hai una libreria lenta o incompleta hai comunque un 
problema)


Enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Enrico Bianchi]

On 07/11/2015 05:03 PM, Enrico Bianchi wrote:
Panic da quello che ho visto manda in traceback l'applicativo, ovvero 
e` l'equivalente di un raise in Python o di un throw in Java. Quello 
che vorrei fare io e` il catch 
Cercando mentre stavo scrivendo questa email mi sono imbattuto in 
proprio in quello che cercavo, ovvero nel builtin recover(), che non fa 
altro che fare il catch di panic(). In altre parole, l'esempio da me 
riportato, potrebbe diventare qualcosa del genere:


package main

import (
  "fmt"
)

func Sum(a int, b *int) int {
defer func() {
if r := recover(); r != nil {
fmt.Println("Panic error:", r)
}
}()

return a + *b;
}

func main() {
var first int
var second *int

first = 1
second = nil
fmt.Println(Sum(first, second))
}

Che non e` proprio quello che intendevo, ma ci si avvicina molto...

Enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Enrico Bianchi]

On 07/03/2015 03:36 PM, enrico franchi wrote:

 Parli di override o di overload?

Oddio, confondo sempre i termini...
Quello che mi interessava fare era semplicemente questo:

func Sum(a, b int) int {
  return a + b
}

func Sum(a, b float) float {
  return a + b
}

Certo, posso usare anche SumInt e SumFloat, ma diventa molto piu` 
complesso, ovvero potrei avere un caso in cui non so il tipo di 
variabile e prima me lo devo andare a cercare (a meno di non fare 
evidenti cast di variabili). Per inciso, ricordo un thread su di un 
gruppo Facebook in cui si criticava specificatamente la mancanza di 
questa caratteristica (e in cui era uscita anche questa cosa simpatica: 
http://play.golang.org/p/Isoo0CcAvr )



Credo che tu non abbia chiara la gestione degli errori in Go.

Guarda, faccio prima a farti vedere cosa intendo: prendiamo questo caso:

package main

import (
  "fmt"
)

func Sum(a int, b *int) int {
return a + *b;
}

func main() {
var first int
var second *int

first = 1
second = nil
fmt.Println(Sum(first, second))
}

Questo codice genera, ovviamente, un runtime error in quanto passo un 
puntatore nil come argomento della somma. Ora, per gestire questa 
situazione, posso sicuramente fare un check che le variabili siano 
valorizzate, ma questo non mi protegge da altri "imprevisti". Per 
capirci, una situazione del genere in Python la gestirei cosi`:


def sum(a, b):
return a + b

if __name__ == "__main__":
try:
print(sum(1, None))
except:
print("Argh!")

(il che potrebbe essere deprecabile in alcuni contesti, mentre in altri, 
e.g. per gestire la morte prematura delle connessioni da parte di un 
client, potrebbe essere una facility non indifferente)


(o meglio, della versione castrata che e' implementata nei vari 
Python, Java, C++ e combriccola con cui sei probabilmente familiare)

Per curiostia`, perche` sarebbero castrate?


puoi usare panic.
Panic da quello che ho visto manda in traceback l'applicativo, ovvero e` 
l'equivalente di un raise in Python o di un throw in Java. Quello che 
vorrei fare io e` il catch



(vedi gli esempi nella stdlib di Go)

Uhm, a quali esempi ti riferisci?

Io personalmente trovo che la gestione degli errori di Go rende il 
codice complessivamente molto piu' snello.
Dipende dal concetto di snello che hai Per esempio, se per creare un 
file, devo fare questo:


file, err := os.Create(filename)
if err != nil {
  panic(err)
}
defer file.Close()

invece di questo:

try:
with open(filename, "w") as f:
# Codice
except:
raise Exception("Argh!")

beh, io trovo piu` snella e chiara la seconda :)

Enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[enrico franchi]

2015-07-02 23:40 GMT+01:00 Enrico Bianchi :


> Beh, diciamo che l'override dei metodi (o meglio, delle funzioni) mi
> avrebbe fatto comodo in alcuni casi


Parli di override o di overload? Perche' parlare di "override" delle
funzioni non ha alcun senso (visto che si parla di override in qualche tipo
di contesto OO, altrimenti non puoi manco esprimere il concetto).



> , cosi` come la gestione delle eccezioni (no, error da solo non mi e`
> molto utile, intendo proprio try/catch come in python o in java).


Credo che tu non abbia chiara la gestione degli errori in Go. In primo
luogo, per i rarissimi casi in cui veramente hai bisogno della semantica
completa delle eccezioni (o meglio, della versione castrata che e'
implementata nei vari Python, Java, C++ e combriccola con cui sei
probabilmente familiare) puoi usare panic. E a chiunque ti stai facendo una
CR e' chiaro che o sei in uno dei pochi casi in cui vuoi usarlo per il
controllo di flusso (vedi gli esempi nella stdlib di Go) oppure
effettivamente sei nel caso "soccia e qui che ci faccio, flippo il tavolo e
vado a casa". Poi magari qualcuno unflippa il tavolo e va avanti, ma
davvero non avevi alternativa.

Io personalmente trovo che la gestione degli errori di Go rende il codice
complessivamente molto piu' snello.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Carlos Catucci]

2015-07-03 15:04 GMT+02:00 enrico franchi :

Ma il linguaggio davvero inattaccabile io non lo ho visto


Ti sbagli, prova a contestare qualcosa di un applicativo scritto in
monicelli e vediamo come ne esci dopo una supercazzora ;)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[enrico franchi]

2015-07-02 22:54 GMT+01:00 Enrico Bianchi :

> Lo posto piu` che altro per ribilanciare i discorsi su Go e su Python
> visti sul gruppo ;)
>
> http://yager.io/programming/go.html


Riassunto: Go is not Haskell/SML.
No shit, Sherlock!

Ci sono alcuni punti in cui ha indubbiamente ragione. Ma il linguaggio
davvero inattaccabile io non lo ho visto. Io credo che Go sia molto
consistente nelle promesse che fa e come le delivera. I suoi limiti sono
quasi tutti chiari dopo una settimana che uno ci lavora. Quando non sono
accettabili, prendere altro e fine della fiera.


Dal mio canto, posso dire che per alcuni punti mi trovo concorde, inoltre
> essendomi scontrato con questo, direi che i miei dubbi sono molto piu`
> radicati:
> https://blog.cloudflare.com/go-crypto-bridging-the-performance-gap/


Scusa, io quell'articolo non lo ho capito. Nel senso che dovrebbe parlare
delle performance di Go (apparentemente da questo thread), ma in realta' si
mette a spiegare roba sui cripto-sistemi. Che va benissimo, ma non ho
esattamente capito in che modo e' rilevante. Da quello che ho capito la
storia breve e': le implementazioni di un po' di cose rilevanti nella
stdlib di Go sono lente, noi abbiamo fatto una versione piu' veloce e
stiamo cercando di integrarla nella libreria standard. Ok. Credo che lo
stesso si possa dire della stdlib di quasi ogni linguaggio di
programmazione, per vari motivi (ottimizzazione per il caso medio, mancanza
di risorse, errore di API iniziale, non ci possiamo fare niente perche' la
piattaforma e' lenta per i cazzi suoi).

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Manlio Perillo]

2015-07-02 23:54 GMT+02:00 Enrico Bianchi :

> Lo posto piu` che altro per ribilanciare i discorsi su Go e su Python
> visti sul gruppo ;)
>
> http://yager.io/programming/go.html
>
> Dal mio canto, posso dire che per alcuni punti mi trovo concorde,


Go è nato con un motivo ben preciso (personale interpretazione): gli autori
del linguaggio erano stufi di avere a che fare con linguaggi di
programmazione complessi
che però causano infiniti problemi in fase di sviluppo da parte di grossi
team ed in fase di manutenzione.

Tutta la filosofia ed il disegno di Go rispecchiano questo punto di
partenza (tra l'altro esasperata dal fatto che gli autori lavorano in
Google e su una grossa base di codice in C++).

Tra l'altro il problema è reale, perchè io ne sono afflitto *anche* con
Python, ogni volta che devo lavorare su una base di codice scritta da altri.

Riguardo l'articolo, poi, l'autore dimentica che Go ha il package unsafe.

Di certo Go ha dei problemi, ma non sono quelli elencati dall'autore
dell'articolo e sono per lo più problemi di implementazione.
Una cosa che forse manca in Go sono le tagged union, perchè le interfacce
sono effettivamente un pò abusate e non permettono il controllo
dell'allocazione della memoria.

Spero solo che nei prossimi 20 anni i nuovi linguaggi sapranno cogliere
questà "innovazione" portata da Go.

> [...]

Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Enrico Bianchi]

On 07/03/2015 12:11 AM, Nicola Larosa wrote:
 


Interessante, per ora la sto guardando di striscio, domani con la mente 
piu` fresca me la vedo meglio :)



Con cosa ti sei scontrato, esattamente?
Beh, diciamo che l'override dei metodi (o meglio, delle funzioni) mi 
avrebbe fatto comodo in alcuni casi, cosi` come la gestione delle 
eccezioni (no, error da solo non mi e` molto utile, intendo proprio 
try/catch come in python o in java). Il vero problema l'ho avuto pero` 
proprio con TLS/SSL, tanto che a causa della sua lentezza mi sono 
ritrovato che per fare un backup mi ci vogliono piu` di 12 ore. Quello 
che mi fa sperare e` che sto comunque lavorando con un prodotto giovane 
e che, soprattutto, la patch di Cloudflare e` in fase di discussione per 
essere introdotta nel repository mainstream (anche se la questione 
sembra essersi bloccata a causa di problemi di copyright di codice...)


Enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Why Go is not good

[Nicola Larosa]

Enrico Bianchi wrote:
> Lo posto piu` che altro per ribilanciare i discorsi su Go e su Python 
> visti sul gruppo ;)
> 
> http://yager.io/programming/go.html

Brutta abitudine, non mettere la data sui post. Questo è di giugno
dell'anno scorso. Ecco la discussione relativa su Reddit:




> Dal mio canto, posso dire che per alcuni punti mi trovo concorde,
> inoltre essendomi scontrato con questo, direi che i miei dubbi sono
> molto piu` radicati:
> https://blog.cloudflare.com/go-crypto-bridging-the-performance-gap/

Con cosa ti sei scontrato, esattamente?

-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Why Go is not good

[Enrico Bianchi]

Lo posto piu` che altro per ribilanciare i discorsi su Go e su Python 
visti sul gruppo ;)


http://yager.io/programming/go.html

Dal mio canto, posso dire che per alcuni punti mi trovo concorde, 
inoltre essendomi scontrato con questo, direi che i miei dubbi sono 
molto piu` radicati: 
https://blog.cloudflare.com/go-crypto-bridging-the-performance-gap/


Enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python