[Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

[Graham Dumpleton]

BTW, to what extent are the examples in the PEP meant to be able to
work on both Python 2.X and Python 3.X as is.

Does it need to be clarified where examples will only work on Python
3.X, in particular the CGI gateway.

Graham

On 4 January 2011 16:49, Graham Dumpleton <graham.dumpleton at gmail.com> wrote:
> On 4 January 2011 16:39, Guido van Rossum <guido at python.org> wrote:
>> On Mon, Jan 3, 2011 at 7:39 PM, Graham Dumpleton
>> <graham.dumpleton at gmail.com> wrote:
>>> I note one issue which I have expressed concern over previously. In
>>> section 'Handling the Content-Length Header; it says:
>>>
>>> """
>>> Under some circumstances, however, the server or gateway may be able
>>> to either generate a Content-Length header, or at least avoid the need
>>> to close the client connection. If the application does not call the
>>> write() callable, and returns an iterable whose len() is 1, then the
>>> server can automatically determine Content-Length by taking the length
>>> of the first bytestring yielded by the iterable.
>>> """
>>
>> That is copied exactly from PEP 333, i.e. WSGI 1.0. I didn't mean to
>> solicit objections to parts of PEP 3333 that are the same as PEP 333;
>> PEP 3333 is intended only to specify how WSGI 1.0 compliance is
>> supposed to work in Python 3. Some clarifications to the original WSGI
>> 1.0 wordings were actually added to PEP 333 around the same time that
>> PEP 3333 was spun off; AFAIK the changes to PEP 333 were
>> noncontroversial and merely clarifications of how WSGI already works.
>> I don't think you can change the above bit of specification (no matter
>> how bad it is) and still call the resulting spec WSGI 1.0(.x) -- we
>> don't want to rule out WSGI 1.0 compliance of apps or frameworks that
>> would be considered compliant under the original 1.0 spec.
>
> I don't believe this really causes a compliance issue as it is a
> requirement on the WSGI server, not the WSGI application and doesn't
> cause any existing WSGI applications to break.
>
> It also says 'can' and not 'must' so technically WSGI servers are not
> currently obligated to do it as I read it and certainly mod_wsgi
> doesn't do it any more because it was causing problems for people.
>
> But then, since it does say 'can' and not 'must' any WSGI server
> implementers who know better can just ignore it anyway if it if left
> in, and it can be dealt with in any new major revision.
>
> Graham
>