Re: [Web-SIG] Draft PEP: WSGI 1.1

2010-04-15 Thread Graham Dumpleton
On 16 April 2010 15:19, Paul J Davis wrote: > > > On Apr 15, 2010, at 11:53 PM, Graham Dumpleton > wrote: > >> On 16 April 2010 13:29, Paul Davis wrote: >>> On Thu, Apr 15, 2010 at 10:08 PM, Graham Dumpleton >>> wrote: On 16 April 2010 11:41, Graham Dumpleton wrote: > I haven't

Re: [Web-SIG] Draft PEP: WSGI 1.1

2010-04-15 Thread Graham Dumpleton
On 16 April 2010 13:29, Paul Davis wrote: > On Thu, Apr 15, 2010 at 10:08 PM, Graham Dumpleton > wrote: >> On 16 April 2010 11:41, Graham Dumpleton wrote: >>> I haven't read what you have done yet >> >> And still haven't. Don't know when I will get a chance to do so. >> >> Two points from a quic

Re: [Web-SIG] Draft PEP: WSGI 1.1

2010-04-15 Thread Paul Davis
On Thu, Apr 15, 2010 at 10:08 PM, Graham Dumpleton wrote: > On 16 April 2010 11:41, Graham Dumpleton wrote: >> I haven't read what you have done yet > > And still haven't. Don't know when I will get a chance to do so. > > Two points from a quick scan of emails. > > 1. The following section of PEP

Re: [Web-SIG] Draft PEP: WSGI 1.1

2010-04-15 Thread Graham Dumpleton
On 16 April 2010 11:41, Graham Dumpleton wrote: > I haven't read what you have done yet And still haven't. Don't know when I will get a chance to do so. Two points from a quick scan of emails. 1. The following section of PEP needs to be updated: """ 1417 Apart from the handling of ``close()`

Re: [Web-SIG] Draft PEP: WSGI 1.1

2010-04-15 Thread Graham Dumpleton
I haven't read what you have done yet, but if you have done so already, ensure you read: http://bitbucket.org/ianb/wsgi-peps/src/ This is Ian's and Armin's previous go at new specification. It though tried to go further than what you are doing. Also read: http://blog.dscpl.com.au/2009/09/road

Re: [Web-SIG] Draft PEP: WSGI 1.1

2010-04-15 Thread Manlio Perillo
And Clover ha scritto: > [...] >> 8. The value passed to the 'write()' callback returned by >>'start_response()' should be a byte string. Where native strings >>are unicode strings, a native string type can also be supplied, in >>which case it would be encoded as ISO-8859-1. > > Weren'

Re: [Web-SIG] Draft PEP: WSGI 1.1

2010-04-15 Thread And Clover
Dirkjan Ochtman wrote: 1. The application is passed an instance of a Python dictionary containing what is referred to as the WSGI environment. All keys in this dictionary are native strings. For CGI variables, all names are going to be ISO-8859-1 and so where native strings are unico

Re: [Web-SIG] Draft PEP: WSGI 1.1

2010-04-15 Thread Manlio Perillo
Dirkjan Ochtman ha scritto: > Mostly taking Graham's list of issues and incorporating it into PEP 333. > > Latest revision: http://hg.xavamedia.nl/peps/file/tip/wsgi-1.1.txt > > Let's have comments here (comments in the form of diffs are > particularly welcome, of course). Remember, the idea is n

Re: [Web-SIG] Draft PEP: WSGI 1.1

2010-04-15 Thread Manlio Perillo
Dirkjan Ochtman ha scritto: > [...] > --- pep-0333.txt 2010-04-15 14:46:02.0 +0200 > +++ wsgi-1.1.txt 2010-04-15 14:51:39.0 +0200 > @@ -1,114 +1,124 @@ > [...] > Abstract > > > [...] > -Thus, simplicity of implementation on *both* the server and framework > -

[Web-SIG] Draft PEP: WSGI 1.1

2010-04-15 Thread Dirkjan Ochtman
Mostly taking Graham's list of issues and incorporating it into PEP 333. Latest revision: http://hg.xavamedia.nl/peps/file/tip/wsgi-1.1.txt Let's have comments here (comments in the form of diffs are particularly welcome, of course). Remember, the idea is not to change or improve WSGI right now,

Re: [Web-SIG] WSGI and start_response

2010-04-15 Thread Dirkjan Ochtman
On Thu, Apr 15, 2010 at 11:09, Manlio Perillo wrote: > Ehm, the purpose of WSGI 2.0 is precisely to remove start_response and > write callable with it... Right, there you go! Cheers, Dirkjan ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://

Re: [Web-SIG] WSGI and start_response

2010-04-15 Thread Manlio Perillo
Dirkjan Ochtman ha scritto: > [...] >> Such a significant change as removing the requirement for write() >> should also not be done within a minor version of the WSGI >> specification because anything that works with WSGI 1.0 should still >> work with WSGI 1.1 and vice versa. On that basis it can't