Re: [Python-Dev] [Web-SIG] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

2010-09-21 Thread Chris McDonough
On Tue, 2010-09-21 at 12:09 -0400, P.J. Eby wrote:
 While the Web-SIG is trying to hash out PEP 444, I thought it would 
 be a good idea to have a backup plan that would allow the Python 3 
 stdlib to move forward, without needing a major new spec to settle 
 out implementation questions.

If a WSGI-1-compatible protocol seems more sensible to folks, I'm
personally happy to defer discussion on PEP 444 or any other
backwards-incompatible proposal.

- C


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Web-SIG] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

2010-09-21 Thread Ian Bicking
On Tue, Sep 21, 2010 at 12:47 PM, Chris McDonough chr...@plope.com wrote:

 On Tue, 2010-09-21 at 12:09 -0400, P.J. Eby wrote:
  While the Web-SIG is trying to hash out PEP 444, I thought it would
  be a good idea to have a backup plan that would allow the Python 3
  stdlib to move forward, without needing a major new spec to settle
  out implementation questions.

 If a WSGI-1-compatible protocol seems more sensible to folks, I'm
 personally happy to defer discussion on PEP 444 or any other
 backwards-incompatible proposal.


I think both make sense, making WSGI 1 sensible for Python 3 (as well as
other small errata like the size hint) doesn't detract from PEP 444 at all,
IMHO.

-- 
Ian Bicking  |  http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Web-SIG] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

2010-09-21 Thread Ian Bicking
On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby p...@telecommunity.com wrote:

 The Python 3 specific changes are to use:

 * ``bytes`` for I/O streams in both directions
 * ``str`` for environ keys and values
 * ``bytes`` for arguments to start_response() and write()


This is the only thing that seems odd to me -- it seems like the response
should be symmetric with the request, and the request in this case uses str
for headers (status being header-like), and bytes for the body.

Otherwise this seems good to me, the only other major errata I can think of
are all listed in the links you included.

* text stream for wsgi.errors

 In other words, strings in, bytes out for headers, bytes for bodies.

 In general, only changes that don't break Python 2 WSGI implementations are
 allowed.  The changes should also not break mod_wsgi on Python 3, but may
 make some Python 3 wsgi applications non-compliant, despite continuing to
 function on mod_wsgi.

 This is because mod_wsgi allows applications to output string headers and
 bodies, but I am ruling that option out because it forces every piece of
 middleware to have to be tested with arbitrary combinations of strings and
 bytes in order to test compliance.  If you want your application to output
 strings rather than bytes, you can always use a decorator to do that.  (And
 a sample one could be provided in wsgiref.)


I agree allowing both is not ideal.


-- 
Ian Bicking  |  http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Web-SIG] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

2010-09-21 Thread P.J. Eby

At 12:55 PM 9/21/2010 -0400, Ian Bicking wrote:
On Tue, Sep 21, 2010 at 12:47 PM, Chris McDonough 
mailto:chr...@plope.comchr...@plope.com wrote:

On Tue, 2010-09-21 at 12:09 -0400, P.J. Eby wrote:
 While the Web-SIG is trying to hash out PEP 444, I thought it would
 be a good idea to have a backup plan that would allow the Python 3
 stdlib to move forward, without needing a major new spec to settle
 out implementation questions.

If a WSGI-1-compatible protocol seems more sensible to folks, I'm
personally happy to defer discussion on PEP 444 or any other
backwards-incompatible proposal.


I think both make sense, making WSGI 1 sensible for Python 3 (as 
well as other small errata like the size hint) doesn't detract from 
PEP 444 at all, IMHO.


Yep.  I agree.  I do, however, want to get these amendments settled 
and make sure they get carried over to whatever spec is the successor 
to PEP 333.  I've had a lot of trouble following exactly what was 
changed in 444, and I'm a tad worried that several new ambiguities 
may be being introduced.  So, solidifying 333 a bit might be helpful 
if it gives a good baseline against which to diff 444 (or whatever).


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com