[Python] Re: Quale framework

[Manlio Perillo]

Nicola Larosa ha scritto:
>> 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.
> 

Avete pensato di aprire un ticket su 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.
> 

Quindi mi confermi che non si può disabilitare ed usare invece un eager
loading.

> 
>> 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.
> 

Esattamente.
L'unico vantaggio è che decido io cosa far girare in un thread separato
e a volte conviene farci girare l'intera view.

Pensa inoltre a cosa succede con le generic view e l'interfaccia
amministrativa!

> 
>> 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.
> 

Io lo sto per publicare:
http://developer.berlios.de/projects/nadbapi


Credo sia venuto fuori abbastanza bene.
Ho implementato un:
- Pool
- Engine
- MetaData

personalizzati per Twisted, che permettono una buona integrazione
(ad esempio engine.create(foo) restituisce una deferred,
e lo stesso foo.select().execute() - se lo si vuole, io di solito
preferisco usare i decoratori.


Se interessa, sto per publicare anche l'altro progetto per la gestione
dei forms:
http://developer.berlios.de/projects/nforms


A breve seguiranno la mia reimplementazione di guard e un package per la
gestione di un calendario (ispirato allo standard ical).

> 
>> 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.
> 

E ne vale la pena? ;-)
Non si fa prima a copiare alcune idee di Django e portarle a
Twisted Web + SQLAlchemy ?



Saluti  Manlio Perillo