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.
_______________________________________________
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
