[Python] un bel dilemma

[Nadir Sampaoli]

Il 27/lug/2015 10:50, "enrico franchi" <enrico.franchi a gmail.com> ha
scritto:
>
> Per fare questo devi stravolgere il linguaggio. In pratica devi fare
scomparire il concetto di statement. Che va bene.
> 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ì).
>
> 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.

>
> Comunque la "semantica del corpo della funzione" (che non mi e' chiaro
cosa intendi) non sembra a prima vista il problema.
Intendo il significato che assume la sequenza di istruzioni contenute nella
definizione di una funzione
>
> Diciamo che per poter dire che "return e' obbligatorio" (che risolverebbe
il problema di cui sopra) devi essere in grado di dimostrare staticamente
che ogni path di esecuzione incontra un return. Che probabilmente non e'
eccessivamente complicato da fare.
>
> E ovviamente avresti un botto di funzioni che finiscono con return None.
Oggettivamente non e' che mi piace troppo... pero' va bene cosi'.
Ma io vorrei proprio l'opposto, cioè che il return sia facoltativo (e solo
necessario nel caso di un early return).
>>
>> Il null implicito fa molto php.
>
> 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.

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

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

Poi, vabbè, evitiamo proprio di iniziare il discorso null/bottom, penso si
sia tutti d'accordo ;)

--
Nadir
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150727/40072af0/attachment.html>