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)
array => a:N:{chiavi=>valori} (dove N è il numero di chiavi)
chiavi possono essere int o stringa, i valori possono essere
qualunque altro tipo serializzato, innestato o non
classi => O:N1:"ObjectName":N2:{parametri=>valori} (dove N1 è la lenght
del nome o il totale dei bytes usati ed N2 è il numero di parametri)
parametri=>valori sono come per gli array ad eccezione dei parametri
che penso non possano essere di tipo int ma solo stringa
parametri privati o protected sono racchiusi tra \000 e \000 i
protected hanno anche un asterisco se non erro
fine, manca solo "N;" che è il serializzato di un null
Allora non capisco... I metodi non li puoi trasferire da javascript a
python, puoi semplicemente trasferire lo stato.
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.
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?
perchè i dizionari non sono istanze di oggetti ma appunto dizionari ?
perchè non puoi usare o inviare classi client / server e gestirne lo stato ?
Castrare? Bisognerebbe conoscerlo python prima di avanzare ipotesi :).
...
Prima mi spieghi cosa significa quello che hai scritto. Mi riferisco a
'manipolarlo su ogni client'.
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 {}
Senza contare la totale inutilita` del serializzare oggetti arbitrari
quando quello che vuoi e` semplicemente inviare un dizionario.
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 ?
Che una volta chiamato user come variabile sul client puo` essere
usato attraverso user.nomeutente come se fosse un oggetto.
ma non puoi usare un metodo, come se fose istanza di classe ...
Io questo non lo chiamerei castrare, lo chiamerei evitare di lavorare
il doppio.
e chi lavora il doppio ? lavoro per la lib, finita quella basta ... la
lib è finita, mancano dettagli ...
Che io faccio gia` cosi` senza dover trasmettere oggetti. Pazienza eh :).
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
Ma che dici? polimorfismo variabile client / server?
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.
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)
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à ...
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
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
Ecco cosa tocca fare in JS come in Python (almeno credo sia così,
illuminatemi altrimenti) per ritrovare la len "fasulla" del PHP
L'assurdo non è la stringa in byte , l'assurdo è che non c'è modo di non
avere la stringa in bytes.
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)
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.
... in php unicode praticamente non esiste, ci stanno ancora lavorando
... cmq ho scritto che mi ero sbagliato, so che sono differenti anche se
non so bene quanto non essendomi mai posto il problema
Ma stiamo usando python per cui mi sfugge il nesso.
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.
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 ...
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 ?
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.
si, non è compatibile con le stringhe UTF-8 , invia liste, tuple e dict
e ritorna sempre e solo dict, non invia ne riceve Classi.
Che ne dici di dare una guardata alla mia di classe ? Che riceve anche
liste, gestisce utf-8 e classi ?
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.
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 ?
E le precedenti sono?
guardati il manuale
Questo lo dici tu pero`. Il mio browser con gmail la pensa
diversamente quando apre un popup dicendomi che lo script e` non
responsivo.
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 ...).
Sforzo inutile.
Per quale motivo sarebbe uno sforzo inutile ??? ... ammesso che a te non
importi niente di questa versione, perchè io dovrei farne a meno ?
A giudicare da quello che hai scritto sopra direi che il problema e`
piu` che un errore semplice.
Si, come dici tu
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
