On 02/13/2014 05:03 PM, Daniele Varrazzo wrote:
> - 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)
Forse sono pignolo, ma "la bugia dei widechar non regge" non vuol dire
quasi nulla visto che:
- non specifichi cos'è un widechar (è un codeunit a 16 bit, o un
codepoint memorizzato in 32?)
- non chiarisci in che modo non regge
Python da questo punto di vista non ha nessun problema, con Py3.3
l'astrazione unicode non mi sembra sia leaky e comunque mi risulta che
tutte le distro linux fornissero da diversi anni solo le wide build di
python di default
insomma: di default le cose funzionano bene da anni... anche se sono
d'accordo che il fardello cognitivo del ricordarsi di "fallire
graziosamente" sulle narrow build fosse un deal breaker
> - tipicamente l'i/o non richiede encoding/decoding
Questo vuol dire che se i dati che leggi non sono codificati
correttamente te ne accorgi proprio nel mezzo dell'elaborazione
essere lazy spesso è una cosa positiva... ma ha i suoi tradeoff
> 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.
>
D'accordo, spero chi programma in Go non parta dalle assunzioni sbagliate
penso sarebbe stato meglio fare di len("whatever") un compile error in
Go, e fornire una funzione size() allo scopo... size si presta di meno
ad essere fraintesa come "lunghezza di un testo"
> 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
Anche Python è un linguaggio opinionato: solo perchè a te non piacciono
i bytes literals (così mi sembra), non vuol dire che "paghi sempre
l'overhead necessario" :P
--
xmpp: berda...@gmail.com
bitmessage: BM-2cTYXfGiSTsnx3righ6aHcJSWe4MV17jDP
gpg fingerprint: 3F8D53518012716C4EEF7DF67B498306B3BF75A0 (used just
for signing commits)
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
