On Fri, 18 Aug 2006 19:09:26 +0200, Andrea Giammarchi <[EMAIL PROTECTED]> wrote:
usato male anche JSON è pericoloso, tanto quanto qualunque chiamata via HTTP
...
Chiaro ma e` piu` difficile usare male qualcosa che usarlo e basta.
già definito dal PHP, formato serialize / unserialize di php
Trovo questo modo di introdurre una roba di php in python piuttosto
discutibile, ad ogni modo: come funziona questo formato?
bisogna avere un Q.I. molto basso per pensare di trasportare un oggetto che
lavora su filesystem in javascript.
Allora non capisco... Se il tuo 'oggetto' e` un contenitore di tipi builtin
tutto quello che stai facendo e` assolutamente inutile. I metodi non li puoi
trasferire da javascript a python, puoi semplicemente trasferire lo stato. In
python pero` gli oggetti non sono altro che dizionari, allora perche`
complicarsi la vita per scrivere tutto sto popo` di roba quando basta saper
trasmettere dizionari?
Detto questo, dite di apprezzare tanto l'astrazione e vi castrate con questa
possibilità ?
Castrare? Bisognerebbe conoscerlo python prima di avanzare ipotesi :).
Inviare un oggetto User, manipolarlo su ogni client, aggiornarlo e salvarlo
sul db o su un cookie, ad esempio, credi sia così inutile sul web ?
Prima mi spieghi cosa significa quello che hai scritto. Mi riferisco a
'manipolarlo su ogni client'. Senza contare la totale inutilita` del
serializzare oggetti arbitrari quando quello che vuoi e` semplicemente inviare
un dizionario. Che una volta chiamato user come variabile sul client puo`
essere usato attraverso user.nomeutente come se fosse un oggetto.
Io questo non lo chiamerei castrare, lo chiamerei evitare di lavorare il doppio.
Non parlo di new User().name e basta, parlo anche di metodi ben definiti
anche sul client come un me.login() che se da un true autentica l'utente,
programmazione ad oggetti client tanto quanto sul server, facile, sicuro,
cos'altro dire ?
Che io faccio gia` cosi` senza dover trasmettere oggetti. Pazienza eh :).
no, non puoi, se vuoi avere anche la possibilità di manipolare oggetti a
polimorfismo variabile client / server (non so cosa abbia appena detto ma è
l'unica cosa che mi veniva da dire).
Ma che dici? polimorfismo variabile client / server?
Le classi e la OOP la conoscete molto bene e non capisco questo accanimento
contro il trasporto di oggetti.
Che significa numeri veri senza encoding diverso?
utf8 ... in php serializzare 'à' può produrre, in charset non UTF-8,
s:1:"à"; .... in un charset UTF8 o con dati salvati in UTF8 produce invece
s:2:"à"; .... il 2 non è la length della stringa, è il numero di bytes usati
per essa. Questa caratteristica rallenta la riconversione in UTF8 ma solo
col PHP, se JS è usato con Python o C# questa "features" non è necessaria,
quindi nessun rallentamento.
Decisamente non sai cosa siano gli encoding... E non ti biasimo venendo da php.
Nel mondo esistono due tipi di stringhe. stringhe di bytes e stringhe di testo.
Le stringhe di byte sono tali perche` codificate in un certo modo, la funzione
len() su di esse ritorna appunto la lunghezza di tale stringa.
Le stringhe di testo invece sono in unicode e la funzione len() ritorna il
numero di caratteri.
Perche` e` assurdo che la stringa di byte (ovvero una stringa di testo
codificata in utf-8) debba ritornare i caratteri e non la lunghezza? Perche` se
non gli dici che encoding usa non c'e` alcun modo per differenziare i caratteri
che la compongono.
Noto tanta confusione riguardo alle stringhe dagli utenti php. Per quanto si
puo` capire per PHP unicode e UTF-8 sono la stessa cosa, non mi stupisce dunque
che il comportamento della len sia fuori dalla comprensione umana.
Per maggiori informazioni:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know
About Unicode and Character Sets (No Excuses!)
http://www.joelonsoftware.com/articles/Unicode.html
facciamo a capirci ... la classe Pear per "serializzare" e "deserializzare"
JSON, per quanto ottimizzata, è un mostro di lentezza perchè deve fare un
char by char con non so quante regexp per ogni stringa che incontra. La
versione compilata non è quasi mai presente negli hosts e quindi usare
quella classe è un suicidio per prestazioni e risorse.
Ma stiamo usando python per cui mi sfugge il nesso.
Stando a questo, usare serialize invece di JSON premette veramente di creare
applicativi enormenente complessi capaci di gestire una "enorme" utenza.
Io lo faccio gia` usando json, e lo fanno tantissimi altri developer python.
Che ne dici di evitare di pensare a python come a quel accrocchio di php?
si, lo so, ma la PHP_Serializer ha tutti i tricks possibili per far si che
non si noti la differenza tra le due versioni e delega comunque il compito
al client, nel caso di PHP.
Come fa a delegare il compito al client? Inoltre PHP_serializer si chiama
PHP_serializer, prima di implementarla, anche se utilissima, sarebbe bene
imparare cio` che esiste gia` in python.
non ho approfondito ma pare pseudo compilino e mettano in cache e siano più
veloci di almeno un 20% rispetto le precedenti.
E le precedenti sono?
La facilità di un eval non mi interessa affatto quando il problema dei siti
è sempre il server e raramente i calcoli sul client.
Questo lo dici tu pero`. Il mio browser con gmail la pensa diversamente quando
apre un popup dicendomi che lo script e` non responsivo.
Un modulo in C sicuramente più veloce del solo Python per fare una
PHP_Serializer per quest ultimo che non sprechi troppe risorse .... cosa che
ho già scritto, ma che non va per via di un.NET framework ...
Sforzo inutile.
Parlavo di UTF-8, errore mio.
A giudicare da quello che hai scritto sopra direi che il problema e` piu` che
un errore semplice.
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
