Lawrence Oluyede ha scritto: > On Fri, Apr 25, 2008 at 3:09 PM, Manlio Perillo > <[EMAIL PROTECTED]> wrote: >> No, non è affatto necessario. > > Certo, ma io parlavo di comodità di API, per questo esistono le > librerie e poi i framework. >
Anche io. >> E lo stesso per l'oggetto Response, wsgiref contiene una classe Headers >> per gestire gli headers, infatti io uso quella. > > È quel che ho detto io. Alla fine finiresti con usare delle funzioni > di utility, che siano scritte da te o meno :) > Si, ma appunto WSGI è nato per essere così; non è una libreria. Il mio dubbio riguarda come debbano essere scritte queste librerie di supporto. Se aumentare l'astrazione, oppure se cercare di restare a basso livello. >> In Python abbiamo la fortuna di avere dizionari che possono contanere >> qualsiasi oggetto, perchè mai dobbiamo introdurre una classe Request? > > Perché ciclare, iterare o interrogare un dizionario ha meno semantica > che request.params o request.is_authenticated. Boh, probabilmente sfugge qualcosa a me perchè non vedo grosse differenze in semantica tra: environ['is_authenticated'] e request.is_authenticated e non capisco perchè parli di ciclare ed iterare sul dizionario. > Non sto sostenendo che sia utile o fondamentale usare astrazioni, solo > che a volte è comodo. > >> Avere oggetti di questo tipo mi sembra più che altro una necessità che >> si ha nei linguaggi staticamente tipizzati, ma non di certo in Python. > > Cosa c'entra la tipizzazione del linguaggio con un API? > Perchè con i linguaggi a tipizzazione statica devi per forza introdurre una oggetto aggiuntivo per gestire lo stato della request. >> Tutto lo stato (incluso le opzioni, ad esempio caricate da un file di >> configurazione tramite un middleware) sono nel `environ`. > > Come in Pylons > Ah, non lo sapevo. >> Se un middleware non è ben scritto e "rompe" la tua applicazione, non lo >> usi. Quale è il problema? > > Certo, e magarti di devi scrivere tu la funzionalità per la quale in > un qualsiasi framework ben fatto (non faccio nomi... Django) ti basta > importare una linea e scrivere un if > Mi faresti un esempio pratico? In effetti a tutt'oggi non sono ancora riuscito a vedere un esempio (con commenti) di middleware scritto male. E' davvero così difficile sistemare questi middleware? >> > Tra l'altro framework >> > come Pylons wrappano la tua applicazione con 3 o 4 middleware ogni >> > volta, il che rende difficile qualsiasi tipo di debug cross-middleware >> > (data la natura opaca del modello) >> > >> >> >> Mi interessa questo aspetto, mi potresti dare maggiori informazioni? > > Crea una Pylons application, vai a guardare middleware.py o fai > partire l'applicazione e fai "paster shell" esplorando l'oggetto app > che ti viene fornito > >> Io fino ad ora non ho incontrato problemi, anzi con i middleware (ma >> fino ad ora direi che ne sto usando solo di semplici) trovo che >> l'applicazione si gestisca meglio. > > Io preferisco il modello Django, non ne faccio segreto con nessuno. Anche a me piace Diango, anche se certe cose sono fatte effettivamente male (ma vabbe, non si può sperare di fare tutto bene). > Trovo che WSGI sia una gran cosa per sostituire CGI e per comunicare > con un web server, un po' meno per il collage. Ma infatti WSGI è nato per comunicare con il web server ;-). > Ma questa è la mia > esperienza da settembre con Paste e Pylons, nulla più > Le cose sono tre: 1) WSGI 1.0 è stato scritto male 2) WSGI 1.0 è troppo difficile da usare bene 3) Paste e Pylons sono scritti male Manlio Perillo _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python