[Python] mod_python ed il giusto handler

Ven 18 Ago 2006 20:33:37 CEST

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