[Web-SIG] Revising environ['wsgi.input'].readline in the WSGI specification

[Graham Dumpleton]

2008/11/18 Tres Seaver <tseaver at palladion.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>>> At 08:49 PM 11/17/2008 +0100, Manlio Perillo wrote:
>>>> Ian Bicking ha scritto:
>>>>> [...]
>>>>> We need to propose a change to the WSGI specification.  I propose, in
>>>>> "Input and Error Streams"
>>>>> (http://www.python.org/dev/peps/pep-0333/#input-and-error-streams) we
>>>>> change it to have "readline(hint)" and expand Note 3 to include
>>>>> readline as well as readlines, removing Note 2.  Also I suppose some
>>>>> sort of change note in the specification?
>>>>> Does this sound like a sufficient change to the spec, and are there
>>>>> any objections to the change?
>>>> Fine for me, but of course we need to do this as:
>>>> 1) Errata to WSGI 1.0
>>>> or
>>>> 2) WSGI 1.1
>>>> or
>>>> 3) WSGI 2.0
>>>>
>>>> You can't just modify the current WSGI 1.0 spec.
>>>>
>>>> I'm for 2), with the other clarifications about WSGI we have discussed
>>>> in the past.
>>> I'm more inclined towards #1.
>>
>> I'm not sure, since it is an API change; of course if there was an error
>> in the API this should be an errata, but there is a rationale behind the
>> current API.
>>
>> I'm fine, however, with an amendment.
>
> Isn't the rationale completely defeated by the equivalent, relaxed form
> for 'readlines' (note #3).  That was why I voted +1:  I couldn't see
> that relaxing 'readline' to match 'readlines' would make life any harder
> on server implementers.

I would be for (1) errata or amendment as reality is that there is
probably no WSGI implementation that disallows an argument to
readline() given that certain Python code such as cgi.FieldStorage
wouldn't work otherwise.

For such a clarification on existing practice, I see no point in
having to change wsgi.version in environ as it would just cause
confusion.

I would also like to see other changes to WSGI specification but now
is not the time, let us at least though get this obvious issue with
API dealt with. After that we can then perhaps have a discussion of
future of WSGI specification and whether there really is any interest
in future versions with more significant changes. Although, personally
I will not be holding my breath for that to happen. :-)

Graham