[Python] Re: Quale framework

[Nicola Larosa]

> Nicola Larosa ha scritto:
>> Ovviamente l'ideale, usando Twisted, sarebbe di non usare per niente i
>> thread, o almeno limitarli all'indispensabile, come l'accesso al 
>> database. In quel caso non si può passare per WSGI, che non supporta
>> gli eventi asincroni, ma bisogna scrivere un apposito handler di
>> Django usando oculatamente i Deferred di Twisted (magari completando
>> quello già iniziato che mi ritrovo casualmente sul disco ;-D ).

Manlio Perillo wrote:

> Ti stai riferendo a: http://code.djangoproject.com/ticket/2904 ?

No, non l'avevo visto, grazie per il riferimento. Mi riferisco a un abbozzo
di handler scritto da un mio amico (hi, pr0gg3d!) col mio aiuto.

Il ticket da te indicato cerca di mantenere la compatibilità con WSGI: il
nostro cerca di integrare direttamente Twisted e Django.


>> A quel punto l'intera architettura è asincrona, tranne le parti dove
>> si continuano a usare i thread, e bisogna seguire ovunque il principio
>> guida di Twisted di non scrivere codice bloccante.

> La vedo ardua dato che puoi accedere a codice bloccante in modo non 
> controllabile quando usi un database.
> 
> Ad esempio, a quanto ho capito, viene usato sempre il lazy loading, 
> quindi una chiamata a obj.xxx può causare una query.

Questo è infatti lo scoglio principale.


> Una soluzione potrebbe essere quella di eseguire l'intera view in un 
> thread (e transazione) separati.

Questo approccio è meno invasivo, non devi propagare tanti Deferred in
giro, però non è molto diverso dall'approccio attuale via WSGI.


> E' quello che volevo fare con Nevow, ma SQLAlchemy si è rivelato molto 
> flessibile. Quello che ho fatto è stato semplicemente scrivere dei
> decoratori:
> 
> @engine.transact def getXXXList(conn, ...): ...
> 
> @engine.transactSession def getYYYList(conn, sess, ...): ...

Abbiamo fatto qualcosa di molto simile, con SQLAlchemy e Twisted, in un
progetto a cui sto lavorando.


> Non ho idea se lo stesso si possa fare agevolmente con Django (e devo 
> dire che non ho molta voglia di indagare).

L'approccio "light" continua a essere sostanzialmente multithreaded, cosa
già fornita dall'integrazione WSGI. L'approccio invasivo converte una
maggior parte dell'architettura al modello di Twisted, ma da un lato non è
facile da scrivere, e dall'altro sconvolge le API di Django e lo rende
incompatibile con i siti sviluppati per la versione ufficiale.


-- 
Nicola Larosa - http://www.tekNico.net/

I have been working on a design doc for restricted execution of Python
as part of my dissertation for getting Python into Firefox to replace
JavaScript on the web. -- Brett Cannon, June 2006