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
2015-07-17 14:33 GMT+01:00 Davide Muzzarelli d.muzzare...@dav-muz.net:
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
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
2015-07-17 14:46 GMT+02:00 Davide Muzzarelli d.muzzare...@dav-muz.net:
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
2015-07-17 0:53 GMT+02:00 Enrico Bianchi enrico.bian...@ymail.com:
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
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
2015-07-16 23:53 GMT+01:00 Enrico Bianchi enrico.bian...@ymail.com:
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
2015-07-17 14:01 GMT+01:00 Davide Muzzarelli d.muzzare...@dav-muz.net:
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
2015-07-17 13:50 GMT+01:00 Carlos Catucci carlos.catu...@gmail.com:
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
2015-07-17 15:10 GMT+02:00 enrico franchi enrico.fran...@gmail.com:
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.
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
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
2015-07-11 16:03 GMT+01:00 Enrico Bianchi enrico.bian...@ymail.com:
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
2015-07-13 12:01 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com:
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,
2015-07-13 11:55 GMT+02:00 enrico franchi enrico.fran...@gmail.com:
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
2015-07-13 14:49 GMT+02:00 enrico franchi enrico.fran...@gmail.com:
2015-07-13 12:01 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com:
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
2015-07-13 14:56 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com:
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
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
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
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,
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
2015-07-02 22:54 GMT+01:00 Enrico Bianchi enrico.bian...@ymail.com:
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
2015-07-03 15:04 GMT+02:00 enrico franchi enrico.fran...@gmail.com:
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 ...
2015-07-02 23:40 GMT+01:00 Enrico Bianchi enrico.bian...@ymail.com:
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
2015-07-02 23:54 GMT+02:00 Enrico Bianchi enrico.bian...@ymail.com:
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
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:
On 07/03/2015 12:11 AM, Nicola Larosa wrote:
https://www.reddit.com/r/programming/comments/29fp6w/why_go_is_not_good_will_yager/
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
27 matches
Mail list logo
