Re: [Python] [OT] pgBadger
2014-02-13 9:31 GMT+01:00 Giovanni Porcari giovanni.porc...@softwell.it: Che dire... grazie Perl ? Non chiederti cosa il tuo linguaggio preferito possa fare per te ma piuttosto cosa tu puoi fare per il tuo linguaggio preferito. Riscrivi pgbadger in python ;) 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
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
Il giorno 13 febbraio 2014 12:20, Manlio Perillo manlio.peri...@gmail.comha 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
2014-02-13 12:20 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com:
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
2014-02-13 11:12 GMT+00:00 Stefano Bossi ste.bo...@gmail.com: 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
2014-02-13 13:01 GMT+00:00 Carlos Catucci carlos.catu...@gmail.com: 2014-02-13 12:20 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: 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
Il 13 febbraio 2014 15:35, enrico franchi enrico.fran...@gmail.com 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-M-S L ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] It's 1999 all over again
2014-02-13 15:24 GMT+01:00 enrico franchi enrico.fran...@gmail.com: 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
[Python] Leggere tag RFID con PySerial
Ciao a tutti,
ho questo lettore RFID:
http://www.apromix.it/product.asp?IdProdotto=999
Da linux mi viene creato il dev ttyUSB0
Ho scritto il seguente codice:
import serial
if __name__ == '__main__':
buff = ''
ser=serial.Serial('/dev/ttyUSB0',125000,timeout=0)
while True:
a=ser.read(ser.inWaiting())
buff = buff + a
print a
print len(buff)
if '\n' in buff:
lines = buff.split('\n')
last_received = lines[-2]
print last_received
Il tutto sembra funzionare nel senso che qualcosa arriva tramite la seriale.
len(buff) aumenta ogni volta che avvicino la carta ma con print a non mi
viene mostrato alcun numero/carattere.
Sapete dirmi come decodificare quello che arriva?
Sembra non arrivare mai un /n.
Grazie per ogni aiuto.
Ciao
Matteo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] It's 1999 all over again
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
2014-02-13 16:07 GMT+01:00 Daniele Varrazzo p...@develer.com: 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
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
[Python] Vi è mai capitato? (Select su SQL)
Ciao a tutti, mi è capitata una cosa strana: faccio un select su una tabella, semplicissimo select *, la tabella ha 92 campi, ma il fetchall mi restituisce 93 valori di cui l'ultimo in più è una data ed è uguale al penultimo e terz'ultimo campo [omissis] 0.0 1799-12-31 00:00:00 1799-12-31 00:00:00 66650112 (ultimo campo della tabella correttamente nullo) 1799-12-31 00:00:00 (campo in più) La query è semplicissima ovvero: self.query = SELECT * \ FROM dbo.IM_JobsSummary \ WHERE ((dbo.IM_JobsSummary.Job)= ? ); self.values = (Job,) self.cur.execute(self.query,self.values) result= self.cur.fetchall() A voi è mai capitata? Idee? Ciao e grazie Piergiorgio___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] It's 1999 all over again
On February 13, 2014 4:22:45 PM CET, Manlio Perillo manlio.peri...@gmail.com 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] Vi è mai capitato? (Select su SQL)
2014-02-13 16:43 GMT+01:00 piergiorgio pancino piert...@yahoo.it: A voi è mai capitata? Idee? Dovresti dirci almeno su che database su cui la esegui, sistema operativo, meglio se anche versione degli stessi. 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
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
Re: [Python] Leggere tag RFID con PySerial
ser=serial.Serial('/dev/ttyUSB0',125000,timeout=0)
Sei sicuro che quel lettore sia impostato a 125000 baud? Non conosco
quel modello, ma quelli che mi sono capitati a tiro usavano velocità
inferiori.
Sapete dirmi come decodificare quello che arriva?
Sembra non arrivare mai un /n.
Non è detto che il lettore trasmetta un /n come se fosse un lettore
di codice a barre. Controlla se il numero di bytes ricevuti è sempre
lo stesso e verifica i dati letti il codice nell'rfid come verifica.
Cmq nella documentazione tecnica non c'è nulla di utile?
--
| /
| \Byte - Andrea Briganti
Blog: http://kbyte.snowpenguin.org
Museo archeologia informatica: http://www.verdebinario.org
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] It's 1999 all over again
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
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
Re: [Python] It's 1999 all over again
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 grin 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
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] Vi è mai capitato? (Select su SQL)
Beh! potrebbe essere sybase Il giorno 13 febbraio 2014 21:58, Carlos Catucci carlos.catu...@gmail.comha scritto: 2014-02-13 21:55 GMT+01:00 Carlo Miron mi...@python.it: Dallo schema ``dbo``, scommetterei su M$ $QL $erver. E, di concerto, M$ Window$. Inoltre, se ricordo bene, ``1799-12-31`` e` il curiosissimo valore minimo accettato dal campo DATE del medesimo. A te Sherlock Holmes ti fa un baffo ;) Carlos, o meglio Dr. Watson -- Je suis marxiste, de tendance Groucho. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python -- * Nicola Gramola (° - linux addicted - keep calm and clear cache - keep it simple - Linux Counter: 324870 http://linuxcounter.net - AViLUG: http://www.avilug.it/ - Calendario attività: http://www.avilug.it/doku.php/calendario ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
