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. Questo porta alle
conseguenze che:
- sono più efficienti in memoria di utf16/32
- 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)
- tipicamente l'i/o non richiede encoding/decoding
- accedere ai codepoint lo fai con interfaccia sequenziale, non con un
array. Se mi ricordo bene (non tocco Go da un anno) ci sono interfacce
che streamano rune partendo da stringhe.
Quindi direi che le stringhe in Go non sono "vere" stringhe, come in
Python:
http://play.golang.org/p/6Q7KoyuEA1
Il programma stampa 6, non 2 come mi sarei aspettato da un linguaggio
che supporta un tipo builtin per le stringhe.
utf8.RuneCountInString(s) restituisce 2.
Cosa devi sapere più spesso: quanti caratteri contiene una stringa o
quanti byte ne occupa il buffer? 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). 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? Molte volte 2 è la risposta giusta. In
termini di occupazione 19 è la risposta giusta. 15 è una risposta
interessante? Forse si, ma non mi viente in mente dove. Sia 2 che 15
richiedono una certa quantità di parsing per essere ottenute. Con Python
paghi sempre l'overhead necessario per avere la risposta 15 in o(1), che
ti serva o meno. Se ti serviva 19 dovevi aprire il file in binario ed
usare un'interfaccia radicalmente diversa (str[n] -> str, bytes[n] ->
int). Con Go paghi l'overhead del decoding solo quando serve.
È 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...
-- Daniele
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
