[Python] Filtrare un carattere.

[Manlio Perillo]

2015-03-22 19:23 GMT+01:00 enrico franchi <enrico.franchi a gmail.com>:

>
>
> 2015-03-22 16:24 GMT+00:00 Manlio Perillo <manlio.perillo a gmail.com>:
>
>> 2015-03-22 17:06 GMT+01:00 enrico franchi <enrico.franchi a gmail.com>:
>>
>>>
>>> 2015-03-22 15:35 GMT+00:00 Manlio Perillo <manlio.perillo a gmail.com>:
>>>
>>>> Tra l'altro il tutto è complicato dal fatto, AFAIK, che ciascuno degli
>>>> operandi può avere effetti collaterali.
>>>> Ad esempio:
>>>> https://play.golang.org/p/jc0vKCWFu7
>>>>
>>>
>>> Scusa non comprendo... in C (e in Go) && introduce un sequence point.
>>> Quindi *sai* l'ordine in cui le cose sono valutate.
>>>
>>
>> Logical operators apply to boolean values and yield a result of the same
>> type as the operands. The right operand is evaluated conditionally.
>> Senza il "conditionally", il compilatore potrebbe evaluare `*p` anche se
>> `p != ni`l è falso.
>>
>
> Si, ovvio. Ma non capisco quale sia il tuo punto.
>

Il punto è che voglio gli operatori corto circuitati per avere un
comportamente sempre ben definito.
AFAIK se && in Go non fosse corto circuitato, il compilatore potrebbe
valutare `*p == 2`anche se p è nullo.


> In realtà, come dici dopo, Go non ha la nozione di sequence point.
>>
>
> Veramente, rileggendo quello che ho scritto, mi e' scappato un Go di
> troppo e ho scritto una minchiata. Ovvero, in C & *non* ti da un sequence
> point.
>
> In Go, invece, come dicevo piu' sotto, te lo da. Appunto perche' in C una
> generica espressione non ti da garanzie sull'ordine di valutazione (per
> esempio invece , lo fa && lo fa || lo fa, etc). Viceversa, in Go il
> linguaggio ti dice l'ordine di valutazione delle cose, che vuole dire che
> essenzialmente ogni operazione introduce un sequence point o giu' di li.
>
>
Quello che volevo dire è che la specifica del linguaggio non parla mai di
sequence point, a differenza del C (ed è una delle parti più complesse del
linguaggio).


> Ovvero se in go scrivi f() & g() sai che f() sara' completamente valutata
> prima di iniziare a valutare g() [nota, go routine et similia non contano,
> perche' se dentro f c'e' qualcosa tipo go h(), il side effect e' "lanciare
> una go-routine che esegue h, i side effect di h non contano).
>
>
>>
>>> Dopo di che mi gira il cazzo perche' in Go non c'e' un singolo modo
>>> decente per convertire un booleano in intero (no, fare un if non e' un modo
>>> decente) e per *nessuna* ragione che a me paia sensata (per favore,
>>> qualcuno mi spieghi il perche') & e | non funzionano con operandi
>>> booleani.  Voglio dire, sarebbero operazioni perfettamente definite e type
>>> safe. WTF!
>>>
>>>
>> La risposta ufficiale credo sia : "ti scrivi delle funzioni apposite "
>>
>
> E la risposta alla risposta ufficiale e' fare torreggiare un dito medio
> alto quattro piani. :)
>
> Cioe', davvero... e' una delle cose che non comprendo. Veramente... Go mi
> e' piaciuto un sacco, mi ha intrigato un sacco. Posso arrivare a dire che
> dopo Python nessun linguaggio mi aveva intrigato altrettanto... ma ci sono
> una piccola serie di cose che proprio non riesco a digerire.
>

All'inizio la pensavo come te, e in alcuni punti lo penso ancora.
Però dopo averlo usato ne apprezzi meglio la semplicità.

Spero proprio che la semplicità, dopo i "danni" fatti dal C++, sia
l'eredità di Go per i futuri linguaggi.


Ciao  Manlio
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150322/731195af/attachment-0001.html>