On Fri, 18 Aug 2006 20:33:37 +0200, Andrea Giammarchi <[EMAIL PROTECTED]> wrote:
Valentino Volonghi aka Dialtone ha scritto:
Trovo questo modo di introdurre una roba di php in python piuttosto
discutibile,
io non introduco niente ... la libreria lavora in background, l'introduzione
del formato serialize di PHP è lo stesso identico concetto di JSON, esistono
versioni di serialize / unserialize per quasi lo stesso numero di linguaggi
eh ... non è una novità e permetterebbe a tale libreria di lavorare su più
linguggi server invece che su uno solo, tutto qua
ad ogni modo: come funziona questo formato?
int => i:N;
float => d:F;
bool => b:N; (dove N è 0 o 1 a seconda che sia True o False)
string => s:N:"stringa"; (dove N è la lunghezza della stringa solo se questa
non è stata encodata in utf8 e non contiene caratteri multi-bytes)
E questo come e` possibile? Puoi inviare solo ascii?
e hai detto niente ... visto che lo stato ti permette di ricostruire, sul
client se presente, o sul server, se presente, un'istanza aggiornata
dell'oggetto.
Si ho detto niente. Un oggetto e` stato e metodi assieme. Se hai solo stato
usare gli oggetti non e` un bene ma un male perche` introduci complessita`
senza motivo. Inoltre se il tuo sogno e` tenere aggiornate le istanzi degli
oggetti tra server e client vivrai una vita grama e ricca di spiacevoli
sorprese.
perchè i dizionari non sono istanze di oggetti ma appunto dizionari ?
Embe`? L'object system di javascript e` comunque diverso da quello di python e
comunque devi riscrivere la classe sia in python che in javascript. Basta
passare gli argomenti per istanziarla lato javascript, tanto _NON_ devono fare
le stesse cose perche` _NON_ sono le stesse ed e` bene che _NON_ vengano neanche
lontanamente rese simili perche` confonderebbero lo sviluppo mischiando logica.
perchè non puoi usare o inviare classi client / server e gestirne lo stato ?
Perche` la tua frase sopra non ha senso. L'"e" e` assolutamente inutile perche`
per quello che fai e` la stessa cosa non una cosa in piu`.
significa che ogni client si gestisce la sua istanza delel sue classi,
significa un approccio completamente OO anche sul client, usando anche
classi e non solo {}
A parte che l'approcio completamente OO non significa nulla. Ma non vedo come
questo modo di serializzare de-serializzare oggetti possa far cambiare
l'approcio.
Sono due cose _COMPLETAMENTE_ diverse. Uno e` la trasmissione di stato da un
server al client e l'altro e` un modello di sviluppo dei client. Sono due
livelli
completamente separati.
prima dici del po po di roba, poi mi parli dell'inutilità di inviare stati
di oggetti, quidi implementeresti un metodo dedicato che a seconda della
classe assegna eventualmente quello o quell'altro parametro all'istanza
dell'oggetto ??? ... io invio istanze, non devo fare altro, inutile eh ? per
me non lo è mai stato, sarò io che ho i paraocchi bucati ?
Si. Faccio un esempio del codice javascript lato client su cui lavoro
abitualmente visto che probabilmente quello di cui parlo e` piu` complesso di
quello che sembra:
Wirc = {};
Wirc.Controller = Nevow.Athena.Widget.subclass('Wirc.Controller');
Wirc.Controller.methods(
function connect(self, nickname) {
self.nickname = nickname;
self.callRemote('connect', nickname);
},
function disconnect(self) {
self.callRemote('disconnect');
},
function send(self, line) {
var action_index = line.indexOf("/action");
var me_index = line.indexOf("/me");
var me_pos = action_index > -1 ? action_index : me_index;
if (me_pos > -1) {
var arr = line.split(" ");
var lst = MochiKit.Base.filter(function(elem) {
if ((elem == "/action") || (elem == "/me")) {
return false;
} else {
return true;
}
}, arr);
line = lst.join(" ");
self.callRemote("action", line);
append_message("*", self.nickname + " " + line);
} else {
self.callRemote("send", line);
append_message(self.nickname, line);
}
var node = MochiKit.DOM.getElement('inputForm');
node.inputLine.value = "";
},
function receive(self, user, msg) {
append_message(user, msg);
},
function updateTopic(self, message) {
MochiKit.DOM.replaceChildNodes('topic', message);
},
function updateUsers(self, users) {
var userlist = MochiKit.DOM.getElement('usersList');
try {
MochiKit.DOM.removeElement('to-remove');
} catch (e) { /*I don't care */ }
for (var i = 0; i < users.length; i++) {
var li = MochiKit.DOM.LI({}, users[i]);
userlist.appendChild(li);
}
},
function info_joined(self, user) {
append_message(user, user+' joined');
self.updateUsers([user]);
},
function info_left(self, user ) {
append_message(user, user+' left');
},
function info_quit(self, user, msg) {
append_message(user, 'quit: '+msg);
var userlist = MochiKit.DOM.getElement('usersList');
MochiKit.Iter.forEach(userlist.children, function (item) {
if (item.innerHTML == user) {
MochiKit.DOM.removeElement(item);
}
});
}
);
Io uso JSON e mi sembra di usare un approcio a oggetti piuttosto spinto lato
client. Giuro inoltre che potrei mostrarti una tonnellata di javascript molto
piu` complesso di questo che utilizza ancora JSON.
ma non puoi usare un metodo, come se fose istanza di classe ...
Il metodo lo devi scrivere comunque in javascript quindi questo non c'entra
niente.
e chi lavora il doppio ? lavoro per la lib, finita quella basta ... la lib è
finita, mancano dettagli ...
Lavori il doppio perche` il tuo modello e` enormemente piu` complesso da
gestire.
si, pazienza, tanto dato i tuoi discorsi lavori solo con dizionari, chissà
quali "stratagemmi" per ricreare i metodi, stratagemmi inutili quando puoi
inviare già un oggetto con quel metodo, poi l'invio di più oggetti non ne
parliamo
Vedi sopra. Ma te lo ripeto perche` ti e` difficile capirlo evidentemente:
non puoi inviare metodi con la serializzazione ma solo lo stato quindi i metodi
devi comunque scriverli per cui non mischiare troppi argomenti.
Intendo dire (in modo sicuramente ridicolo e mi ero scordato che qui non
passava niente nemmeno se prontamente commentato) che una classe client può
avere (come no) un riscontro con la classe server e vice-versa ma che le due
classi si comportano in modo differente sul client e sul server.
Come? E questo cosa ha a che fare col polimorfismo?
Non è mica detto che la classe client debba avere il metodo fileWrite
presente invece in quella server, è però vero che lo stato dell'istanza può
viaggiare e permetterti di usare obj.fileWrite("test") sul server, ed
obj.getText sul client, metodo che fa altro, inesistente sul server, come è
inesistente fileWrite sul client (methodTable decide cosa trasportare e cosa
no)
Cosa c'entra? Non puoi trasportare i metodi. Devi scriverli i metodi.
Stessa classe, stesso stato, metodi uguali con o senza lo stesso nome con
possibilità di usare operazionidifferenti a seconda dell'utilizzatore,
client o server.
Poi in realtà ACE permette anche questo ma si basa sulla semplicità ...
Permettimi ma non posso che dissentire, di semplice il modello non ha nulla.
quindi se vuoi mandargli un metodo della classe Pippo di nome sayHello in
ACE senza alzare un dito avrai la possibilità di fare
var p = new Pippo();
p.sayHello.call();
p.sayHello.result = function(str){alert(str)}
fine, volendo hai anche
p.sayHello.progress = function(perc){alert(perc)}
per avere un riscontro in percentuale della ricezione dei dati
E` tremendo. Quindi io posso accedere a tutti gli oggetti che voglio lato
client facendo quello che desidero attraverso quegli oggetti? Che poi e` molto
poi semplice fare una cosa tipo:
callRemote("sayHello").addCallback(function(str) {alert(str)})
oppure
function progress(perc) {alert(perc)}
lasciando al server il compito di chiamare perc quando necessario senza
scomodare
il client.
Decisamente non sai cosa siano gli encoding...
... decisamente non ci capiamo ...
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?
e chi l'ha mai detto ? Io ho solo detto che è una pecurialità di php e php
"soltanto" ed è la causa del rallentamento in serializzazione /
unserializzazione con JS o gli altri linguaggi quando devi interagire con il
formato serializzato di php abilitando il supporto UTF-8
def __slen(self, s):
charcode = 0
result = 0
slen = len(s)
if self.UTF8:
while slen:
slen = slen - 1
try:
charcode = ord(s[slen])
except:
charcode = 65536
if charcode < 128:
result = result + 1
elif charcode < 2048:
result = result + 2
elif charcode < 65536:
result = result + 3
else:
result = result + 4
else:
result = slen
return result
charcode non sara` mai piu` di 256 a meno che s non sia unicode perche` per
ottenere
piu` di 256 ti serve un carattere multibyte che non otterrai mai senza usare
unicode.
[ord(x) for x in "ˀ߯ßð¯ßð¯ßʼø,-≤˛©ˍˇ®þ¸´®þ®¶ʼ¥,øʼ…˝-˚"]
[203, 128, 195, 159, 194, 175, 195, 159, 195, 176, 194, 175, 195, 159, \
195, 176, 194, 175, 195, 159, 202, 188, 195, 184, 44, 45, 226, 137, 164, \
203, 155, 194, 169, 203, 141, 203, 135, 194, 174, 195, 190, 194, 184, 194, \
180, 194, 174, 195, 190, 194, 174, 194, 182, 202, 188, 194, 165, 44, 195, \
184, 202, 188, 226, 128, 166, 203, 157, 45, 203, 154]
len("ˀ߯ßð¯ßð¯ßʼø,-≤˛©ˍˇ®þ¸´®þ®¶ʼ¥,øʼ…˝-˚")
70
len(u"ß")
1
ord(u"ß")
223
ord("ß")
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: ord() expected a character, but string of length 2 found
ord("ß"[0])
195
ord("ß"[1])
159
ord(u"˝")
733
len("˝")
2
ord("˝"[0])
203
ord("˝"[1])
157
Ecco cosa tocca fare in JS come in Python (almeno credo sia così,
illuminatemi altrimenti) per ritrovare la len "fasulla" del PHP
Non c'e` nessuna len fasulla.
L'assurdo non è la stringa in byte , l'assurdo è che non c'è modo di non
avere la stringa in bytes.
Assolutamente sbagliato e questo perche` non conosci gli encoding.
len(unicode("ˀ߯ßð¯ßð¯ßʼø,-≤˛©ˍˇ®þ¸´®þ®¶ʼ¥,øʼ…˝-˚", "utf-8"))
36
len("ˀ߯ßð¯ßð¯ßʼø,-≤˛©ˍˇ®þ¸´®þ®¶ʼ¥,øʼ…˝-˚")
70
cmq noi piaccapari ignoranti e biasimati parliamo di questa "caratteristica
assurda" da talmente tanto tempo che in PHP6 da mesi si parla di colmare le
problematiche con UTF-8 ... ed infatti hanno messo nativamente UTF-16 (LOL)
Ma il problema non lo risolverete ancora :).
cmq ho scritto che mi ero sbagliato, so che sono differenti anche se non so
bene quanto non essendomi mai posto il problema
Ora pero` sei obbligato a portelo perche` in python questo problema non e`
nascosto goffamente dal linguaggio ma ti viene sbattuto in faccia facilmente.
Il nesso è la portabilità della lib, ma a quanto pare avete già
l'onnipotenza in materia e quindi una lib che con una sola scrittura del
client si porta anche in Python, oltre che PHP e C# non vi interessa.
Ma esiste gia` JSON, chissenefrega di una libreria usata in php perhe` in php
JSON e` lento come la fame?
Strano, nell' era del "web js & ajax" avere librerie da non dover riscrivere
anche per il client dovrebbe muovere l'interesse collettivo, proverò con gli
altri linguaggi, abbandono il porting per Python ? Visto che tutto è inutule
e che non si capisce niente dell'intento o le potenzialità della libreria
devo proprio aver cannato linguaggio ...
Esiste gia` JSON, negli altri linguaggi dubito verrai accolto molto
differentemente.
Se vuoi scrivere la tua libreria in python perche` serve al tuo progetto nessuno
te lo impedisce ma e` difficile trovarne l'utilita` quando c'e` gia` JSON che
funziona ed e` _gia`_ implementato in tanti linguaggi e la tua libreria non
porta vantaggi di alcun genere per questo scopo.
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?
Che ne dici di evitare di valutare ancora prima di conoscere ?
PHP lo conosco abbastanza da evitarlo direi e le ultime cose che mi hai detto su
JSON non fanno altro che confermare le mie conoscenze su PHP :).
Per quanto riguarda te non mi sono mai permesso di esprimere valutazioni sulla
tua intelligenza o professionalita`.
si, non è compatibile con le stringhe UTF-8 , invia liste, tuple e dict e
ritorna sempre e solo dict, non invia ne riceve Classi.
Perche` non si possono ne` inviare ne` ricevere classi ma solo il loro stato il
che significa inviare un dict (che se proprio uno vuole farsi del male
e` self.__dict__).
Che ne dici di dare una guardata alla mia di classe ? Che riceve anche
liste, gestisce utf-8 e classi ?
Non mi spiacerebbe ma l'ultima volta che l'ho fatto il risultato e` stato
disastroso per cui prima mi firmi un documento che ti impedira` di farmi causa
se la mia reazione sara` vigorosa, poi guardo il tuo sorgente.
Tra l'altro il tizio della serialize "che esiste già" mi ha già fatto i
complimenti ed ha detto che quanto prima avrebbe aggiornato il suo sito per
segnalare la variante.
E chi e` il tizio?
Il tizio non ha fatto una versione per PyRex ... ma questa che razza di ml
python è ? Open Source, Closed Eyes, Every Other Out of Here ?
Si. Pero` a me piace questo modo di comprendere l'open source dove non esiste
discussione, se io ho un'idea e` giusta per forza perche` e` un'altra idea, non
c'e` la possibilita` che sia sbagliata o che meriti una discussione in cui
l'autore si trova a difendere le sue scelte progettuali. Semplicemente va
accettata e ci si riempie tutti di pacche sulle spalle perche` siamo stati
bravi a creare l'ennesima variante di una libreria che esiste gia`.
va bene, stravolgiamo le convinzioni mondiali sull'utilità del delegare
parte dei calcoli al client in ambito web perchè Gmail su un K6 non gira
bene (ma poi Gmail ha una miriade di codice, la lib invece pesa 15 Kb con 3
classi incluse di cui 2 riutilizzabili, JSL e PHP_Serializer ... ah no,
tutto inutile ...).
A me spiace che una discussione in cui non ho alzato i toni e sto cercando di
capire e consigliare i motivi delle tue scelte sta diventando per te una
questione
personale.
Per quale motivo sarebbe uno sforzo inutile ??? ... ammesso che a te non
importi niente di questa versione, perchè io dovrei farne a meno ?
Ma tu puoi scriverla come ti pare, te lo sto impedendo in qualche modo? Magari
ti sfugge che stiamo discutendo di una tua libreria e riguardo alle tue scelte
di inventare un nuovo formato di serializzazione che non aggiunge nulla a
JSON (non e` piu` semplice da parsare, non e` piu` veloce in Python se sia
il tuo che l'altro li si implementa in Pyrex [ma se nessuno ha implementato
json in C/pyrex/boost/altro significa che non e` un problema per nessuno]).
Nasconde semplicemente il procedimento di serializzazione di oggetti arbitrari
che non va nascosto per varie ragioni che spieghero` solo se avrai voglia
di discutere invece che prenderla sul personale.
A giudicare da quello che hai scritto sopra direi che il problema e` piu`
che un errore semplice.
Si, come dici tu
Gli encoding hai ammesso di non conoscerli perche` con php non ti sei mai posto
il problema... Ora fai l'ironico a riguardo?
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
