Re: [Python] It's 1999 all over again

[Dario Bertini]

"any character in the current locale" non è un concetto ben definito

lo sarebbe se il locale specificasse un "character set", ma da quando
unicode esiste, un character set non è più la stessa cosa di un
encoding... e visto che il locale specifica solo un encoding queste
incomprensioni sono inevitabili



-- 
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

Re: [Python] It's 1999 all over again

[Daniele Varrazzo]

On 2014-02-14 11:08, Manlio Perillo wrote:

On 14/02/2014 00:34, Daniele Varrazzo wrote:

On 2014-02-13 18:50, Dario Bertini wrote:

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


wchar_t è compiler dependent: potrebbe essere anche 8 bit. Tanto per
essere utile.



E' vero che è implementation defined, ma lo standard C99 dice:

wide character
bit representation that fits in an object of type wchar_t, capable of
representing any character in the current locale

Ora, assumendo che il locale corrente permette di gestire l'intero
Unicode, una implementazione corretta dovrebbe avere un wchar_t di 4
octets.

Il fatto che Windows (che assumo/spero supporti l'intero Unicode) ha
una rappresentazione di wchar_t come 2 octets, significa che o io
interpreto male lo standard o Windows non è conforme.


Credo tu non l'abbia interpretato bene. "any character in the current 
locale" si esprime a sufficienza in UTF16, perché il BMP (Basic 
Multilingual Plane, ovvero i codepoint tra  e ) contengono tutti 
gli alfabeti correnti. Gli altri codepoint (da 01 a 10, i "piani 
astrali") contengono simboli speciali e caratteri antichi, niente che 
possa essere necessario in alcun "locale" corrente.


https://en.wikipedia.org/wiki/Plane_(Unicode)#Supplementary_Multilingual_Plane

La scelta di Microsoft è conforme finché non verrà chiesto un locale in 
cuneiforme o in geroglifici meroitici, che richiederebbero UTF32 per 
essere rappresentati /in un singolo wchar_t/. La scelta è pragmatica, 
tipica di mamma MS.


Nota che usare wchar_t a 16 bit non impedisce a un programma in C di 
esprimere tutto l'unicode: I caratteri al di fuori del BMP si possono 
rappresentatre usando "coppie surrogate". Quello che salta è l'identità 
1 wchar_t == 1 codepoint, quindi ancora accesso o(1) al carattere N e 
proporzionalità tra numero di caratteri e lunghezza del buffer.


https://en.wikipedia.org/wiki/Mapping_of_Unicode_characters#Surrogates

Usando i surrogate block è possibile scrivere un documento che mischi 
lingue correnti e paperelle egiziane anche con wchar_t a 16 bit. Essere 
un locale credo sia una proprietà più forte, ma non conosco lo standard 
C99.



-- Daniele

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Manlio Perillo]

On 14/02/2014 00:34, Daniele Varrazzo wrote:

On 2014-02-13 18:50, Dario Bertini wrote:

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


wchar_t è compiler dependent: potrebbe essere anche 8 bit. Tanto per
essere utile.



E' vero che è implementation defined, ma lo standard C99 dice:

wide character
bit representation that fits in an object of type wchar_t, capable of 
representing any character in the current locale


Ora, assumendo che il locale corrente permette di gestire l'intero 
Unicode, una implementazione corretta dovrebbe avere un wchar_t di 4 octets.


Il fatto che Windows (che assumo/spero supporti l'intero Unicode) ha una 
rappresentazione di wchar_t come 2 octets, significa che o io interpreto 
male lo standard o Windows non è conforme.


> [...]


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Dario Bertini]

Uhm, hai scritto troppo e troppe cose con le quali io sono in disaccordo
per poterti rispondere puntualmente, quindi prendo solo l'aspetto
filosofico che secondo me differisce in modo più eclatante

On 02/14/2014 12:34 AM, Daniele Varrazzo wrote:
> un risultato indeterminato va bene. Ma ti prego, non crashare alle 3 di
> mattina per un print.


ecco, questo è l'esatto opposto di quello che voglio


-- 
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

Re: [Python] It's 1999 all over again

[Daniele Varrazzo]

On 2014-02-13 18:50, Dario Bertini wrote:

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


wchar_t è compiler dependent: potrebbe essere anche 8 bit. Tanto per 
essere utile.


Se fosse 16 bit, comunque ti servono 2 unità per esprimere un carattere 
fuori BMP (surrogate pairs)


Se fosse 32 bit, comunque ci sono i caratteri combinanti. Non ne esci.

Cosa non regge è l'idea che se hai widechar, non mi interessa quanto 
wide, comunque né accesso casuale né lunghezza siano operazioni 
genericamente utili. Anche in utf32:


In [3]: s = u'\u0075\u0301'

In [4]: len(s)
Out[4]: 2

In [5]: print s
ú



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


Non lo sapevo. Che spreco. Nessuno usa i caratteri fuori dal BMP  
Non so come verificarlo ma sembra sia così:



sys.getsizeof(u'aa') - sys.getsizeof(u'a')

4



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


Anche in python. Tutto funziona finché non arriva un accento e le cose 
si rompono. Magari si rompono in I/O, mentre tutto quello che occorreva 
era leggere una stringa da un database e scriverla su una pagina web: 
per un programma scritto negli ultimi 10 anni ci sono buone chance che 
entrambi siano utf8 e la codifica/decodifica non era necessaria: un 
accento sarebbe arrivato indenne a destinazione, anche se Python non 
l'avrebbe visto come codepoint singolo.


Il problema sono i dati legacy. Go credo non ne voglia avere a che 
fare, e ne approfitta per fare pulizia. Se scrivi un programma oggi da 
zero sarà bene che faccia tutto con unicode/utf8. Il problema delle 
codifiche 8 bit è un problema che hanno i linguaggi colla, e Go ha 
deciso di semplificare su questo punto e guardare al presente/futuro 
invece che al passato. Anche ora, con tutte le interfacce che gestisco 
(database, web, email, file...) non uso praticamente nessun encoding che 
non sia utf8. Se proprio c'è un input latin1 ok, ci sarà un decoder 
sull'interfaccia che lo converte: non cambia rispetto a Python.



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"


se uno non sa che cosa sta facendo, a livello di usare una stringa 
senza sapere se sono codepoint o una codifica, non vedo la necessità di 
venirgli incontro. Meglio faccia un altro lavoro. Altrimenti rischia di 
centrare male la stringa in cinese nello schermo.


Se per questo vorrei una macchina del tempo per dare una martellata 
sulle dita di chi ha implementato str.encode() e unicode.decode(), 
perpretando sempre di più l'idea che str e unicode siano 
intercambiabili. Ho bestemmiato i miei santi migliori dietro alle 
librerie che chiamano x.decode() qualunque cosa sia x, e siccome va bene 
agli americani va bene a tutti. O meglio magari funziona nella shell ma 
si rompe in crontab perchè una variabile d'ambiente è diversa [1]. Dare 
ad unicode l'interfaccia non di una lista ma di un iterabile avrebbe 
fatto notare che len(unicode) non è un'operazione poi così utile - e se 
proprio ti serve fai len(list(u)). Invece che ha fatto in python3? Ha 
azzoppato bytes rimuovendo l'operatore %, quindi tutto *deve* essere 
[de]codificato. A questo punto ecco il bastone, lì ci sono i cuccioli di 
foca... Ok fine rant :)




È 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


Perché non mi dovrebbero piacere i byte literal? :)

E sì, paghi overhead in codifica (input), elaborazione (4 volte la 
memoria e quindi il tempo per processarla) e decodifica (output) anche 
dove non sarebbe stato necessario: è un fatto che non vedo come si possa 
negare. Usare unicode ovunque mi va benissimo: è giusto ed è il presente 
e il futuro. È la scelta di rappresentarlo internamente come array di 
codepoint che crea delle strozzature. Go non ha queste chicane, il che 
lo rende più efficiente sull'I/O di qualunque magia

Re: [Python] It's 1999 all over again

[Carlo Miron]

2014-02-13 16:22 GMT+01:00 Manlio Perillo ::

> 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.



-- 
©
::

R
 K--S
L
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Manlio Perillo]

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:

 世界

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

Re: [Python] It's 1999 all over again

[Dario Bertini]

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

Re: [Python] It's 1999 all over again

[Daniele Varrazzo]

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:

世界

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

Re: [Python] It's 1999 all over again

[Dario Bertini]

On February 13, 2014 4:22:45 PM CET, Manlio Perillo  
wrote:
>
>
>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.
>


Import "unicode/utf8"
utf8.RuneCountInString

Concordo con te però sul fatto che non fa certo ciò che ci si aspetterebbe da 
una stringa di testo

-- 
Sent from mobile. Please excuse my brevity.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Manlio Perillo]

On 13/02/2014 16:07, Daniele Varrazzo wrote:

On 2014-02-13 13:01, Carlos Catucci wrote:


1. Il tipo *string* si comporta come un *array di byte*, una volta
settati
sono immutabili. Cioè è illegale assegnare un valore a *&s[i]*.

A me sembra una cosa complicata, in C posso cambiare un carattere di un
array di caratteri (una stringa in pratica), e qui mi sembra sia vietato.


In C non esistono stringe. Quello che tu credi di fare ad una stringa lo
stai facendo ad un array di caratteri. Considerare una stringa un array
di cose comporta una serie di svantaggi, a cui forse siamo abituati, ma
svantaggi restano:

- 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

String types

A string type represents the set of string values. A string value is a 
(possibly empty) sequence of bytes. Strings are immutable: once created, 
it is impossible to change the contents of a string. The predeclared 
string type is string.


The length of a string s (its size in bytes) can be discovered using the 
built-in function len. The length is a compile-time constant if the 
string is a constant. A string's bytes can be accessed by integer 
indices 0 through len(s)-1. It is illegal to take the address of such an 
element; if s[i] is the i'th byte of a string, &s[i] is invalid.



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.




Ciao  Manlio

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Carlos Catucci]

2014-02-13 16:07 GMT+01:00 Daniele Varrazzo :

> In C non esistono stringe. Quello che tu credi di fare ad una stringa lo
> stai facendo ad un array di caratteri.


Certo che si. Infatti in C io considero un array di caratteri. In Python ho
un oggetto. Qui non ho capito ancora. Ribadisco, non ho ANCORA capito, devo
leggermi tutto, provarlo e poi posso dire qualcosa.

Volevo solo far notare che le frasi del tipo erano alquanto ambigue e
difficili da interpretare.

Carlos
-- 
Je suis marxiste, de tendance Groucho.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Daniele Varrazzo]

On 2014-02-13 13:01, Carlos Catucci wrote:

1. Il tipo *string* si comporta come un *array di byte*, una volta 
settati

sono immutabili. Cioè è illegale assegnare un valore a *&s[i]*.

A me sembra una cosa complicata, in C posso cambiare un carattere di 
un
array di caratteri (una stringa in pratica), e qui mi sembra sia 
vietato.


In C non esistono stringe. Quello che tu credi di fare ad una stringa 
lo stai facendo ad un array di caratteri. Considerare una stringa un 
array di cose comporta una serie di svantaggi, a cui forse siamo 
abituati, ma svantaggi restano:


- sei legato all'implementazione del carattere (char, utf16, utf32)
- un tipo mutabile non può essere hashato (per rispondere alla tua 
domanda nell'altra mail)


Ha anche il vantaggio di poter accedere con efficienza o(1) al 
carattere N. Questo vantaggio è largamente sopravvalutato (anche da me, 
per molto tempo: c'ho avuto le migliori discussioni con un amico). 
Quanti casi di uso richiedono di accedere al carattere 100 di una 
stringa? Soprattutto quando potresti non sapere se quella stringa è di 
byte in encoding utf8, quindi il byte 100 potrebbe non rappresentare 
neanche un carattere?


"un array di caratteri (una stringa in pratica)" è un'abitudine dura a 
morire, ma dalla sua morte si può guadagnare parecchia igiene mentale.


-- Daniele

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Carlo Miron]

Il 13 febbraio 2014 15:35, enrico franchi 
ha scritto::

> Le stringhe immutabili sono una gran cosa, davvero. Se vuoi un array
> mutabile fai un array di bytes.

di rune (sinonimo di int32). le stringhe go sono utf8.

-- 
©
::

R
 K--S
L
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Carlos Catucci]

2014-02-13 15:24 GMT+01:00 enrico franchi :

> Per certe cose sarebbe proprio perfetto...
>

Per quali? SOlo per sapere, vista la mia ignoranza sull'oGgettO


-- 
Je suis marxiste, de tendance Groucho.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[enrico franchi]

2014-02-13 13:01 GMT+00:00 Carlos Catucci :

>
> 2014-02-13 12:20 GMT+01:00 Manlio Perillo :
>
> Che è più efficiente di Python, restando però molto usabile (non a livello
>> di Python, ma nemmeno a basso livello come C).
>>
>> Con Python se vuoi ottimizzare puoi solo farlo riscrivendo alcune
>> funzioni in C, guidato da un profiler.
>> Per programmi più complessi, Go si posiziona bene come linguaggio "unico"
>> (intendendo che puoi scrivere tutto in un solo linguaggio con un buon
>> bilanciamento di prestazioni e facilità di scrittura/manutenzione codice).
>>
>> La concorrenza direi che è la classica ciliegina sulla torta (a
>> differenza, ad esempio, di Erlang, dove la concorrenza è forse l'*unica*
>> ragione per sceglierlo).
>>
>> Tutto questo ad intuito, non avendo mai usato sul serio Go (non mi
>> piacciono alcune decisioni prese a livello di design).
>>
>
> Io non lo conosco e sto approcciandomi ora a studiacchiarlo.
>  Non mi fa impazzire, non ha la pulizia stilistica del Python ne
> l'immediatezza del C.
>

Frase ad effetto, ma non vuole dire moltissimo... Come immediatezza io lo
trovo piuttosto buono.
Se vuoi ha meno cose "sorprendenti" rispetto al C. Parliamo di un
linguaggio che ti accetta 5[p], voglio dire... non e' tutto rose e fiori.



>  Pero' il mio e' un parere per avere letto una introduzione qui
>
>
> http://okpanico.wordpress.com/2011/03/13/go-specifiche-del-linguaggio-prima-parte/
>

Ora io l'articolo non lo ho letto, ma magari prima di formarti un parere
leggi le introduzioni "top ranked"... no?



>
>
> 1. Il tipo *string* si comporta come un *array di byte*, una volta
> settati sono immutabili. Cioè è illegale assegnare un valore a *&s[i]*.
>
> A me sembra una cosa complicata, in C posso cambiare un carattere di un
> array di caratteri (una stringa in pratica), e qui mi sembra sia vietato.
>
>
Le stringhe immutabili sono una gran cosa, davvero. Se vuoi un array
mutabile fai un array di bytes.


> 2. Come nel C gli indici sono compresi in [0 .. len(a)-1]. I tipi sono
> sempre monodimensionali ma possono essere composti per creare tipi
> multidimensionali.
>

Si, non e' molto chiaro. Credo che voglia dire che in Go, come in C, una
matrice fatta alla naive (per dire) non e' una cosa a se stante, ma e'
realmente un array di array.


> 3. Come per gli array le slice sono sempre monodimensionali ma possono
> essere composte per creare oggetti di più dimensioni. Per gli array di
> array gli array costituenti sono sempre della stessa lunghezza per
> costruzione; diversamente per le slice di slice (o array di slice) le
> lunghezza possono cambiare dinamicamente. Inoltre le slice costituenti
> devono essere allocate individualmente, con *make()*.
>
> Per finire di far fondere il mio cervello che col giu' dalle orecchie (per
> questo devo sbrigrami a concludere questo post)
>
> So come funzionano le slice, e non capisco cosa vuole dire. ;)



-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[enrico franchi]

2014-02-13 11:12 GMT+00:00 Stefano Bossi :

>
> Ma qualcuno di voi ha in produzione qualcosa di scritto in go?
>

Ho visto di tutto. Stiamo facendo una certa pressione per provare ad
introdurre piu' massicciamente Go.
Ma non ha un monte di trazione.

Per certe cose sarebbe proprio perfetto...


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Carlos Catucci]

2014-02-13 12:20 GMT+01:00 Manlio Perillo :

> Che è più efficiente di Python, restando però molto usabile (non a livello
> di Python, ma nemmeno a basso livello come C).
>
> Con Python se vuoi ottimizzare puoi solo farlo riscrivendo alcune funzioni
> in C, guidato da un profiler.
> Per programmi più complessi, Go si posiziona bene come linguaggio "unico"
> (intendendo che puoi scrivere tutto in un solo linguaggio con un buon
> bilanciamento di prestazioni e facilità di scrittura/manutenzione codice).
>
> La concorrenza direi che è la classica ciliegina sulla torta (a
> differenza, ad esempio, di Erlang, dove la concorrenza è forse l'*unica*
> ragione per sceglierlo).
>
> Tutto questo ad intuito, non avendo mai usato sul serio Go (non mi
> piacciono alcune decisioni prese a livello di design).
>

Io non lo conosco e sto approcciandomi ora a studiacchiarlo.
Non mi fa impazzire, non ha la pulizia stilistica del Python ne
l'immediatezza del C. Pero' il mio e' un parere per avere letto una
introduzione qui

http://okpanico.wordpress.com/2011/03/13/go-specifiche-del-linguaggio-prima-parte/

Sara' il redattore dell'articolo che ha espresso le cose in maniera da
apparirmi particolarmente confusa pero':

1. Il tipo *string* si comporta come un *array di byte*, una volta settati
sono immutabili. Cioè è illegale assegnare un valore a *&s[i]*.

A me sembra una cosa complicata, in C posso cambiare un carattere di un
array di caratteri (una stringa in pratica), e qui mi sembra sia vietato.

2. Come nel C gli indici sono compresi in [0 .. len(a)-1]. I tipi sono
sempre monodimensionali ma possono essere composti per creare tipi
multidimensionali.

Esempi:

[32]byte
[2*N] struct { x, y int32 }
[1000]*float64
[3][5]int
[2][2][2]float64  // equivalente a [2]([2]([2]float64))

Non ci ho capito una cippa. Ribadisco che e' stata solo una letta veloce,
ma mi ha davvero confuso i pochi neuroni superstiti.

3. Come per gli array le slice sono sempre monodimensionali ma possono
essere composte per creare oggetti di più dimensioni. Per gli array di
array gli array costituenti sono sempre della stessa lunghezza per
costruzione; diversamente per le slice di slice (o array di slice) le
lunghezza possono cambiare dinamicamente. Inoltre le slice costituenti
devono essere allocate individualmente, con *make()*.

Per finire di far fondere il mio cervello che col giu' dalle orecchie (per
questo devo sbrigrami a concludere questo post)

Carl...
-- 
Je suis marxiste, de tendance Groucho.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Marco De Paoli]

Il giorno 13 febbraio 2014 12:20, Manlio Perillo
ha scritto:

> (non mi piacciono alcune decisioni prese a livello di design).
>

esempio?

...scusa ma mi (ci?) hai incuriosito

ciao,
Marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Manlio Perillo]

On 13/02/2014 12:12, Stefano Bossi wrote:

[...]
Ma qualcuno di voi ha in produzione qualcosa di scritto in go?
Se sì, posso sapere perchè l'avete preferito al python?
Ci sono altri vantaggi grossi oltre ai quelli che riguardano la concorrenza?



Che è più efficiente di Python, restando però molto usabile (non a 
livello di Python, ma nemmeno a basso livello come C).


Con Python se vuoi ottimizzare puoi solo farlo riscrivendo alcune 
funzioni in C, guidato da un profiler.
Per programmi più complessi, Go si posiziona bene come linguaggio 
"unico" (intendendo che puoi scrivere tutto in un solo linguaggio con un 
buon bilanciamento di prestazioni e facilità di scrittura/manutenzione 
codice).


La concorrenza direi che è la classica ciliegina sulla torta (a 
differenza, ad esempio, di Erlang, dove la concorrenza è forse l'*unica* 
ragione per sceglierlo).


Tutto questo ad intuito, non avendo mai usato sul serio Go (non mi 
piacciono alcune decisioni prese a livello di design).




Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Stefano Bossi]

2014-02-12 12:04 GMT+01:00 Carlos Catucci :

>
> On 12 February 2014 11:32, Nicola Larosa  wrote:
>
>> Affinità e divergenze tra il compagno Togl... tra il linguaggio Go e
>> Python lo rendono molto interessante, direi complementare. Una panoramica
>> (il primo commento spoilera la soluzione dell'errore nella prima nota.
>> :-) ):
>>
>
> In effetti ho idea che potrebbe essere appunto il complemento a Python,
> per quelle cose che a Python non riescono al meglio. Diciamo che sono Yin e
> Yang.
>
> Ma qualcuno di voi ha in produzione qualcosa di scritto in go?
Se sì, posso sapere perchè l'avete preferito al python?
Ci sono altri vantaggi grossi oltre ai quelli che riguardano la concorrenza?

Stefano

Carlos
> --
> Je suis marxiste, de tendance Groucho.
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Carlos Catucci]

On 12 February 2014 11:32, Nicola Larosa  wrote:

> Affinità e divergenze tra il compagno Togl... tra il linguaggio Go e
> Python lo rendono molto interessante, direi complementare. Una panoramica
> (il primo commento spoilera la soluzione dell'errore nella prima nota. :-)
> ):
>

In effetti ho idea che potrebbe essere appunto il complemento a Python, per
quelle cose che a Python non riescono al meglio. Diciamo che sono Yin e
Yang.

Carlos
-- 
Je suis marxiste, de tendance Groucho.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] It's 1999 all over again

[Carlos Catucci]

On 12 February 2014 11:32, Nicola Larosa  wrote:

> e spero non mi licenzi perché lo cito in
> pubblico
>

Cazzarola non sapevo fossi un ... Canonico ;)
Complimenti!

Carlos
-- 
Je suis marxiste, de tendance Groucho.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] It's 1999 all over again

[Nicola Larosa]

Su una mailing list interna di Canonical, Mark Shuttleworth ha detto a
proposito del linguaggio Go (e spero non mi licenzi perché lo cito in
pubblico ;-) ):

"It's like the early days of Python; the smart folks are saying
"interesting" and the rest are saying "whitespace?". It's still a very
good first-pass filter."

È la stessa impressione che avevo io: il 2014 è il nuovo 1999, e Go è il
nuovo Python.

Affinità e divergenze tra il compagno Togl... tra il linguaggio Go e
Python lo rendono molto interessante, direi complementare. Una panoramica
(il primo commento spoilera la soluzione dell'errore nella prima nota. :-) ):
:

Does the next decade belong to Go?


A buon intenditor, poche parole. :-)

-- 
Nicola Larosa - http://www.tekNico.net/

No ill will here, [man], but I hope you don't think you'll live forever.
One day you'll be gone and somebody will get their filthy mits on your
code. That's better than having it die with you, don't you think?
 - J. Liles, September 2013
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python