[Python] mod_python ed il giusto handler

[Valentino Volonghi aka Dialtone]

On Fri, 18 Aug 2006 14:40:07 +0200, Andrea Giammarchi <andrea a 3site.it> wrote:
>Gli array in JS sono anche associativi (Array extends Object, quindi non 
>esiste un vincolo sull'uso di array come associativi), molto simili a quelli 
>PHP, improponibili ad esempio in Python (infatti la serializer sceglie se 
>trasportare una dict o una list in automatico, cosa che il progetto 
>ufficioso della python php serializer non fa), ma come per php può 
>trasportare classi Python e sfruttarle, se presenti, anche in JavaScript, o 
>crearle runtime e sfruttarle come oggetti normali.

Non e` mai una buona idea questa ed e` colma di vari pericoli concernenti la sicurezza. Una soluzione a questo tipo di lavoro e` definire bene un protocollo per lo scambio di oggetti dove sia da python che da javascript vengono scritti serializer/unserializer per ogni nuovo oggetto che ha la necessita` di essere trasportato. A conti fatti questo e` abbastanza inutile perche` nessuno ha davvero bisogno di scambiare oggetti python con javascript vista sia l'enorme differenza di capacita` (javascript essendo sandboxed non puo` fare un milione di cose tipo aprire file sul filesystem, pertanto non ha senso serializzare una classe che ha un fd aperto ad esempio).

Che JSON poi non sia il massimo e` anche vero ma scambiando oggetti semplici comprensibili da javascript funziona benissimo e ci puoi scrivere applicazioni enormemente complesse con poca difficolta`.

>In poche parole a parte la fagianata della strlen di php (numeri veri solo 
>senza encoding diverso) il formato serializzato di php lo trovo 

Che significa numeri veri senza encoding diverso?

>assolutamente più efficace di quello JSON ed in php la fatica di conversione 
>non è delegata al server (Pear, stra ottimizzata, stra lenta lostesso) ma al 
>client (comunque rapidissimo su decine di migliaia di valori innestati o 
>meno).

Il server non serializza e sinceramente la vedo dura trasmettere dei dati su socket senza serializzare in qualche modo.

Quando il client trasmette serializza e il server deserializza e vice versa.
JSON comunque ha il vantaggio di avere il parser piu` veloce del mondo lato client... Il browser che fa eval().

>In python dovrei sfruttare una struct (della versione 2.5) oppure leggermi 

Che hanno le struct della versione 2.5? E come le parsi lato javascript? Puoi fare packing/unpacking di binari in javascript con piu` facilita` che un eval?

>qualcosa su PyRex o fare un modulo in C così da colmare il gap in 
>serializzazione / deserializzazione (ma su python non ha molto senso 
>abilitare la conversione in utf8 quindi sia il JS che il python in quel caso 
>sono rapidissimi).

Non mi e` chiaro cosa abbia a che fare Pyrex con questo.

>P.S. JSON-RPC basato su XML tende anche ad aumentare la banda in scambio 
>dati, serialize / unserialize ne prende poca in più di JSON normale (in 
>realtà in certi casi molta di meno non avendo la sfilza di \xAB per ogni 
>stringa unicode) e la serializzazione client mi sembra sia anche più veloce 
>di quella ufficiale JSON per JS, unserialize ovviamente non regge il 
>confronto, un eval post RegExp non ha equivalenti.

Non esistono stringhe unicode che possano essere trasmesse su un socket. Il socket e` byte oriented e unicode no (non si possono trasmettere stringhe senza che vengano codificate in qualche modo).