[Python] un bel dilemma

[enrico franchi]

2015-07-27 19:11 GMT+01:00 Nadir Sampaoli <nadirsampaoli a gmail.com>:
>
> > Pero' poi devi accettare:
> >
> > if a = 3:
> >     print a
> >
> > cosa sara' a?
> Immagino che a sarà qualcosa che può essere paragonato e che può essere
> stampato. Ma, con un po' di fantasia, se ti riferisci al caso in cui a = 3
> non valga, direi che manca l'alternativa (sì, sono di quella corrente lì).
>
Ehm... *se* fosse Python valido, quell'if valuterebbe sempre a vero (a = 3,
varrebbe 3) e stamperebbe 3.
E' un classico baco che si ha in C e linguaggi similari, dove per 1
utilizzo valido e sensato dell'assegnamento come espressione ce ne sono 9
che sono in realta' bachi dove si intendeva fare una comparazione. Come
vedi e' piuttosto facile confondersi. :)



> > Oh, volendo puoi fare stravolgimenti della grammatica per fare
> funzionare comunque come si vuole... ma in generale se vai in direzione del
> "tutto e' un'espressione, ci vai fino in fondo."
> Il che mi sta abbastanza bene.
>
E devi accettare il coso la sopra... non e' che si muoia, eh. Ma non e'
nemmeno che sia chiaramente meglio di non avere il return implicito.

> I linguaggi che menzioni .. a parte che per certi versi Rust non fa una
> cosa troppo diversa da Python. Se non metti return, lui ritorna ().
> Solo se termini l'ultima espressione con un punto e virgola.
>

fn foo() {
    println!("baz")
}

fn main() {
    let x = foo();
    let () = x;
}

Questo funziona, foo ritorna () e non finisce per ;. Mi sono perso quello
che intendevi, credo.


> > Dopo di che il fatto che sia staticamente tipizzato mi fa anche pensare
> che se provi ad usare () per assegnarlo a qualcosa che non dovrebbe avere
> quel tipo intervenga.
> Ed è un bel favore.
>
Oh, si, piuttosto. Se il type system fa meno danni di quelli che risolve
benvenga. Il typing di Go e di Rust (sebbene su diverse scale di "strong")
sono entrambi type system che fanno il loro mestiere. Perfino con Java a
patto di usare i vari FindBugs e le appropriate annotazioni ce la si
cavicchia.

> > Per il resto, gli altri linguaggi che menzioni di fatto hanno altre
> convenzioni: per esempio che l'ultima espressione che compare e' quella che
> viene ritornata. La cosa e' relativamente ovvia e poco sorprendente nei
> linguaggi "veramente" funzionali.
> Che poi nei linguaggi *veramente* funzionali non hai un'ultima espressione
> (il che implicherebbe una sequenza procedurale), ma un'unica espressione.
> > E una volta che hai static typing, anche la gamma di errori che puo'
> causare cala moltissimo. In Ruby? Non cosi' intuitivo, dal mio punto di
> vista. Fra le due, preferisco il None implicito rispetto che "quello che e'
> ultimo implicito".
> Posso chiederti perchè?
>
> Io lavoro per la stragrande maggioranza del tempo in php (no comment
> please) e più di una volta vengo morso da return dimenticati (sarà per via
> che poi la domenica sto su haskell e rust, boh...)
>
Ci saranno anche dei linter per PHP, no?

> Poi, vabbè, evitiamo proprio di iniziare il discorso null/bottom, penso si
> sia tutti d'accordo ;)
>
Fondamentalmente si. Dal punto di vista della type theory pero' *hai*
bisogno di un bottom type logico. Non necessariamente deve essere
esprimibile come un valore: anzi, il problema e' proprio che puoi
esprimerlo come un valore.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150728/fc6b497a/attachment.html>