[Python] It's 1999 all over again

Gio 13 Feb 2014 20:39:48 CET

On 13/02/2014 17:03, Daniele Varrazzo wrote:
> On 2014-02-13 15:22, Manlio Perillo wrote:
>> On 13/02/2014 16:07, Daniele Varrazzo wrote:
>
>>> - sei legato all'implementazione del carattere (char, utf16, utf32)
>>
>> Direi che lo stesso problema è presente, in parte, con Go:
>> http://golang.org/ref/spec#String_types
>
> Il problema è risolto dal fatto che hanno dichiarato che le stringhe
> sono solo 8 bit e sono solo codificate in utf8, mentre l'accesso ai
> codepoint unicode ha un'interfaccia separata.

Che è quello che puoi ottenere anche in C.

> Questo porta alle
> conseguenze che:
>
> - sono più efficienti in memoria di utf16/32

Sicuramente, ma che succede se io non ho problemi di memoria e mi 
interessa invece l'efficienza di esecuzione dei vari algoritmi che 
operano sulle stringhe?  Come scritto tempo fa, questo è proprio uno dei 
problemi di Go: ha delle "regole" imposte dal creatore del linguaggio, 
mentre io preferisco la filosofia del C in cui il programmatore sa 
quello che fa ed il linguaggio deve lasciarglielo fare permettendo anche 
di farlo in modo efficiente.

> - sai che a[n] non è un carattere ma è un byte. La bugia dei widechar
> non regge. Neanche quella di unicode in python che però si rompe al di
> fuori del BMP (a meno che non lo compili 4 byte per carattere blah blah)

Per quello che ne so, puoi usare la rappresentazione che vuoi per una 
stringa (1 byte UTF-8, 2 byte UTF-16, 4 byte UTF-32), e se l'API è 
corretta non dovrebbe rompersi in nessun caso.
Al momento non ricordo il problema specifico di Python; mi confermi che 
dipende interamente dal fatto di aver scelto 2 bytes, oppure se è un bug 
o problema di API esposta?

> - tipicamente l'i/o non richiede encoding/decoding

L'I/O di stringhe direi che *richiede* encoding, almeno fino a quando 
UTF-8 non sarà disponibile ovunque.  E' da molto che non uso Windows, ma 
in XP mi sembra che UTF-8 non lo potevi impostare come encoding di sistema.

> [...]
 >
> Conoscere il numero di caratteri di una
> stringa è un'altra operazione largamente sopravvalutata (non scrivi
> tutti i giorni un algoritmo per centrare una stringa di caratteri non
> proporzionali in uno schermo).

Vero, ma non vedo perchè quei pochi casi non possano essere ottimizzati 
scegliendo una rappresentazione alternativa, se uno lo ritiene necessario.

> Molti algoritmi possono essere espressi
> con un'iterazione sull'input che dura fino al verificarsi di una certa
> condizione (fine dell'input, o altro): per questi non ti serve la
> lunghezza.
>
> Quanti caratteri è lungo:
>
>      <html>世界</html>
>
> dipende dal contesto, no?

Dipende anche da che intendi per carattere.
Sono 2 caratteri, ed N bytes con N che dipende dalla rappresentazione 
interna della stringa.

> [...]
> È un linguaggio opinionato: quando incontra gente opinionata può piacere
> o non piacere :) Trovo la scelta di avere stringhe solo utf8 molto
> razionale nel 201x, anche se richiede aggiustamenti mentali rispetto ad
> abitudini prese nel 197x. Ma allora non esistevano i cinesi, né le
> lettere accentate, né l'€, quindi è comprensibile...
>

Io non ho nulla contro la scelta di avere le stringhe UTF-8 (che, come 
dici, è perfettamente condivisibile), ho qualche dubbio sul fatto di 
offrire *solo* quella.  Ovviamente non parlo della babele che abbiamo 
adesso ad esempio con la gestione delle stringhe in Ruby o PostgreSQL, 
ma almeno avrei seguito la strada di D ed offerto tipi diversi di 
stringhe in base alle rappresentazioni Unicode standard.

Ciao  Manlio