[Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

Salve a tutti,

vi scrivo per parlarvi di un progetto che ho iniziato un circa un mesetto
fa.

Assolutamente non sono qui per "vendervi" un prodotto, visto che non è
ancora pronto, ma sono qui a parlarvi del progetto perchè mi piacerebbe
poter avere aiuti nello sviluppo, e poi sviluppare da soli non è così
divertente (:-)

Il progetto, che si chiama Spyro, è un webframework, scritto nativamente per
Python3. La scelta che mi ha spinto ad avviare questo tipo di progetto è la
totale o parziale assenza di supporto dai webframework attuali, verso questo
ambiente di produzione.
Visto che mi piace stare al passo coi tempi, e che devo sviluppare delle
applicazioni web nuove, ho pensato di iniziare io stesso a sviluppare un
framework.

Non voglio essere troppo prolisso, il codice lo trovate qui [1] e ha
opportuni commenti.
Il progetto si basa su tre principi:
 1- tutti i settaggi devono risiedere in un file esterno.
 2- sempre retrocompatibile.
 3- esplicito è meglio che implicito.

Il codice ha meno dipendenze possibili, perchè queste, essendo progetti di
terze parti potrebbero minare a quello che si vuole ottenere, specialmente
al #2, chiaramente alla fine ognuno usa quello che meglio preferisce, ma lo
scopo primario non è quello di consentire di scambiare prodotti di terze
parti sulla stessa base.

Una cosa che non ho mai sopportato di vari framework è che per passare
dall'ambiente di sviluppo a quello di produzione, quasi sempre devi cambiare
alcune cose al codice, spesso per settaggi cosiddetti hard-coded.
Al #1 ho pensato di porvi rimedio con un file esterno di configurazione,
sfruttando il fantastico YAML, e tutte le features che questo offre per
elaborare il file di configurazione che si passa poi per nome alla classe
Application che elabora il file. Questa è la base dell'applicazione WSGI.
Il vantaggio è quello di potersi basare su uno strumento di verifica che
permette di riconoscere errori vari. In questo modo il codice si scrive una
sola volta: per il testing e per il deploy. Tutto quello che deve cambiare
si cambia nella configurazione, e poi si esegue l'applicazione. In questo
modo si limitano i bug nell'applicazione derivati da errori fatti da
modifiche veloci dei settaggi. Le funzioni che esaminano i settaggi dovranno
essere opportunamente migliorate per garantire maggiore sicurezza.
Il #2 è un po' uno dei principi che muovono l'intera community di Python.
Troppo spesso però (in senso più generale) mi ritrovo io stesso a dover
riadattare i miei programmi per farli girare con nuove versioni delle
librerie o applicazioni di terze parti. Tutto questo non vuol dire che non
ci debbano essere miglioramenti o aggiunte di funzionalità, ma tutto quello
che cambia sotto la "corteccia" non deve minare la funzionalità di un metodo
messo a disposizione, e questi ultimi non devono essere rinominati, rimossi
o eseguire qualcosa di diverso da quanto originariamente previsto (va bene
farlo diverso ma deve fare quello). In questo modo spero di poter garantire
una base su cui lavorare in modo stabile e far girare una applicazione con
una qualunque versione del webframework, senza incompatibilità. Nuove
features e nuovi metodi sono quindi OK, ma piuttosto di rimuoverne uno
obsoleto stando a questo principio bisognerebbe usare un livello di
astrazione e quindi riscrivere il corpo del metodo/funzione e farlo
funzionare con i nuovi metodi.
Il #3 si riferisce un po' in termini generali all'approccio del framework.
Mi piace che le cose siano autoesplicative, e che ci siano opportuni metodi
per salvare i dati e cose simili, senza rendere misterioso come il framework
funziona. I programmatori non devono perdere tempo a capire come e/o perchè
una cosa funziona, ma devono concentrarsi solo sulla propria applicazione.

Il codice probabilmente è da riscrivere in qualche parte o magari solo
migliorare altre parti. Le poche applicazioni web che ho sviluppate per la
maggior parte le ho fatte in PHP (conosciuto Python son passato a cose di
basso livello in C) e da allora la mia mente è sempre rimasta un po' legata
a questo approccio, dove tra dev e deploy cambiano i settaggi del server e
poco o niente del codice. Anche se il web non è mai stato il mio target
primario, almeno non il web che si "vede", avendo lavorato a qualche
applicazione C/C++ di networking tra cui webserver.
Attualmente l'unico server WSGI già pronto che ho trovato per Python3 è
wsgiref e uso quello per i test, ma ho in progetto di riscrivere e
completare un server in C asincrono da interfacciare con le nuovi API
Python3.

Il framework attualmente fornisce tutto il necessario che mi è venuto in
mente per fare una applicazione, compreso il session manager (che magari non
sarà dei migliori ma funziona). Trovate nella cartella "devs/" una
alternativa al session manager che usa un'altro approccio, ma espone a
rischi di sicurezza descritti in cima al file, e comunque l'overhead
descritto nel file TODO [(!4) nella lista Future Versions] avviene solo la
prima volta ed è visibile con "ab" perchè questo non invia all'app gli
header necessari per recuperare il session identifier.
Manca una feature oggi molto diffusa, ovvero il passaggio di argomenti da
parte dello url-dispatcher, nella forma /controller/id/value, è da
aggiungere in una futura release, comunque per ora consente di accedere
facilmente a dati GET, POST, COOKIE e tutte le variabili d'ambiente WSGI.
L'url dispatcher comunque supporta le regexp ed esegue una ricerca lineare
nel dict che descrive le url (ricavato come descritto nella documentazione).

Manca un ORM built-in che però mi piacerebbe implementare sulla falsariga di
Autumn, che sembra comunque non più attivo da tempo. SQLAlchemy lo trovo
davvero molto featured, mi piacerebbe una cosa più semplice (non un
sostituto di SQLAlchemy). Fare un abstraction layer per semplificare le cose
come Elixir implicherebbe che io conosca bene SQLAlchemy cosa che purtroppo
non sò. Elixir stesso non ha supporto a Python3, e l'autore mi ha confermato
che non c'è in cantiere alcun supporto a Python3 (dicendomi addirittura che
forse non ci sarà mai). Per ora il database manager supporta solo pgsql
tramite py-postgresql con query SQL.
Per il templating adesso da default si appoggia a Jinja2, appena altri
engine saranno Python3-ready verranno aggiunti al supporto.
Come noterete tutto è ben integrato e si fà largo uso del Register
(rappresentazione interna dei dati contenuti nel file YAML).

Mancano anche alcuni (ok, tutti tranne uno :s) test perchè quelli che
scrivevo io non erano automatici, in quanto richiedevano l'uso di una
applicazione di test in esecuzione. Spero possiate aiutarmi anche a scrivere
quelli.

Spero di non avervi annoiato, e soprattutto spero che qualcuno sia disposto
ad aiutarmi, anche solo criticando il lavoro o dandomi consigli su come
gestire il progetto. E' il mio primo vero progetto Open Source, ed è sotto
licenza 2-clause BSD ed ogni aiuto è ben gradito (proprio ogni tipo di
aiuto, sottolineo, anche correzioni nei commenti se non sono chiari o
scrittura della documentazione).

Ci sarebbe molto altro da dire, ma preferisco che sia il codice a parlare
(forse ho dimenticato di dire qualcosa di importante, nel caso chiedete), e
se avete bisogno chiaramente resto a disposizione. Se su questa ML creo
disturbi potrei sempre creare una ML su google groups se qualcuno è
interessato.

Quasi dimenticavo, i target principali sono i sistemi *nix e *nix like
(linux, bsd e os x sopra a tutti).

Resto a disposizione, buona serata a tutti.

[1] http://code.google.com/p/spyro/
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20110407/e422836e/attachment.html>