[Python-Dev] WSGI is now Python 3-friendly

P.J. Eby pje at telecommunity.com
Sun Sep 26 15:47:35 CEST 2010


At 07:15 PM 9/25/2010 -0700, Guido van Rossum wrote:
>Don't see this as a new spec. See it as a procedural issue.

As a procedural issue, PEP 333 is an Informational PEP, in "Draft" 
status, which I'd like to make Final after these amendments.  See 
http://www.wsgi.org/wsgi/Amendments_1.0, which Graham created in 2007, stating:

"""This page is intended to collect any ideas related to amendments 
to the original WSGI 1.0 so that it can be marked as 'Final'."""

IOW, there is no intention to treat the PEP as "mutable" going 
forward; this is just cleanup so we can mark it Final.  After that, 
it's an ex-parrot.


>Clarifications of ambiguous/unspecified behavior can possibly rule as
>non-conforming implementations that used to get the benefit of the
>doubt. Best-practice recommendations also have the effect of changing
>(perceived) compliance.

I understand the general principle, but with respect to these 
*specific* changes, any perceived-compliance arguments that were 
going to happen, already happened years ago.  The changes are merely 
to officially document the way those arguments already turned out, so 
the PEP can become Final.

Specifically, the changes all fall into one of three categories:

1. Textual clarification (SERVER_PORT is not an int, iteration can 
stop before all output is consumed)

2. Practical issues with wsgi.input arising from the fact that 
real-world programs needed its behavior to be more "file-like" than 
the specification required...  and which essentially forced servers 
that were not using socket.makefile() to make their emulations work 
like that, anyway (or else be rejected by users).

3. Clarification of behavior that would break HTTP compliance (apps 
or servers sending more than Content-Length bytes) and is therefore 
*already a bug* in any implementation that does it.

Since in all three categories any implementation that did not end up 
following the recommendations on its own is going to have been 
considered buggy by its users (regardless of its formal 
"compliance"), and because the changes do not actually declare the 
buggy behaviors in categories 2 and 3 to be non-compliant, I do not 
see how any of these changes can produce the type of problems you're 
worried about here.

Certainly, if I thought such problems were possible, I wouldn't have 
accepted these amendments.  Likewise, if I thought that changes would 
continue to be made to the PEP past this point, the goal wouldn't be 
getting it to Final status.



More information about the Python-Dev mailing list