[Python] Programmazione web

[Manlio Perillo]

Lawrence Oluyede ha scritto:
> On Fri, Apr 25, 2008 at 3:09 PM, Manlio Perillo
> <manlio_perillo a libero.it> 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