[Python] mod_python ed il giusto handler

[Valentino Volonghi aka Dialtone]

On Fri, 18 Aug 2006 19:09:26 +0200, Andrea Giammarchi <andrea a 3site.it> 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.