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
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
