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

[Graham Dumpleton]

Add another point. FWIW, these are coming up because of questions
being asked on python-dev IRC channel about PEP 3333.

The issue as it came down to was that the PEP may not be clear enough
in explaining that where str() is unicode and as such something like
PATH_INFO, although unicode, is actually bytes decoded as ISO-8859-1,
needed to be re encoded/decoded to get it back to Unicode in the
charset required before use.

They were thinking that because it was unicode already they could use
it as is and not need to do anything. Ie., didn't realise that need to
do:

  path_info = environ.get('PATH_INFO', '')
  path_info = path_info.encode('ISO-8859-1').decode('UTF-8')

for example to get it interpreted as UTF-8 first. They were simply
looking at concatenating new URL bits to the ISO-8859-1 variant from
other unicode strings that weren't bytes represented as ISO-8859-1.

In Python 2.X it was obvious that since it wasn't unicode that you had
to decode it, but confusion may arise for Python 3.X if this
requirement is not explicitly spelled out with a code example like
above.

We all may see it as obvious and yes perhaps it could be covered in
separate articles or commentaries be people, but given this person was
new to it, maybe it is deserving of more explanation in the PEP itself
if they were confused.

It could also be that the PEP covers it adequately already. I am too
tired to read through it again right now.

Graham

On 4 January 2011 20:53, Graham Dumpleton <graham.dumpleton at gmail.com> wrote:
> 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
>>
>