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

[Graham Dumpleton]

On 7 January 2011 17:22, Graham Dumpleton <graham.dumpleton at gmail.com> wrote:
> On 7 January 2011 17:13, Graham Dumpleton <graham.dumpleton at gmail.com> wrote:
>> The version at:
>>
>> http://svn.python.org/projects/peps/trunk/pep-3333.txt
>>
>> still shows:
>>
>>        elif not headers_sent:
>>             # Before the first output, send the stored headers
>>             status, response_headers = headers_sent[:] = headers_set
>>             sys.stdout.write('Status: %s\r\n' % status)
>>             for header in response_headers:
>>                 sys.stdout.write('%s: %s\r\n' % header)
>>             sys.stdout.write('\r\n')
>>
>> so not using buffer there and also not converting strings written for
>> headers to bytes.
>
> So:
>
>        elif not headers_sent:
>             # Before the first output, send the stored headers
>             status, response_headers = headers_sent[:] = headers_set
>             sys.stdout.buffer.write(wsgi_header('Status: %s\r\n' % status))
>             for header in response_headers:
>                 sys.stdout.buffer.write(wsgi_header('%s: %s\r\n' % header))
>             sys.stdout.buffer.write(wsgi_header('\r\n'))
>
> where define up start of file:
>
> def wsgi_header(u):
>    return u.encode('iso-8859-1')
>
> I am still seeing some issue with CRLF but is in my body and with
> conversion of some StringIO in my test.

Solved my CRLF issue. Was caused by what 2to3 did to my code.

Another thing though. For output changed to sys.stdout.buffer. For
input should we be using sys.stdin.buffer as well if want bytes?

Good thing I tried running this. Did we all assume that someone else
was actually running it to check it? :-)

Graham

>> Graham
>>
>> On 7 January 2011 17:00, Graham Dumpleton <graham.dumpleton at gmail.com> wrote:
>>> Stupid question first. When running 2to3 on the example CGI code, why
>>> would it throw back the following. Is this indicative of anything else
>>> that needs to be changed to satisfy some Python 3 thing. The list()
>>> bit seems redundant, but I don't know what the other stuff is about.
>>>
>>> --- xx.py (original)
>>> +++ xx.py (refactored)
>>> @@ -9,7 +9,7 @@
>>>     return u.encode(enc, esc).decode('iso-8859-1')
>>>
>>>  def run_with_cgi(application):
>>> -    environ = {k: wsgi_string(v) for k,v in os.environ.items()}
>>> +    environ = {k: wsgi_string(v) for k,v in list(os.environ.items())}
>>>     environ['wsgi.input']        = sys.stdin
>>>     environ['wsgi.errors']       = sys.stderr
>>>     environ['wsgi.version']      = (1, 0)
>>> @@ -45,7 +45,7 @@
>>>             try:
>>>                 if headers_sent:
>>>                     # Re-raise original exception if headers sent
>>> -                    raise exc_info[0], exc_info[1], exc_info[2]
>>> +                    raise exc_info[0](exc_info[1]).with_traceback(exc_info[2])
>>>             finally:
>>>                 exc_info = None     # avoid dangling circular ref
>>>         elif headers_set:
>>>
>>>
>>>
>>>
>>> On 7 January 2011 16:58, Guido van Rossum <guido at python.org> wrote:
>>>> On Thu, Jan 6, 2011 at 9:47 PM, James Y Knight <foom at fuhm.net> wrote:
>>>>> On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote:
>>>>>> At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote:
>>>>>>> Is that the last thing or do I need to go spend some time and write my
>>>>>>> own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have
>>>>>>> lying around and just do some final validation checks with a parallel
>>>>>>> implementation as a sanity check to make sure we got everything? This
>>>>>>> might be a good idea anyway.
>>>>>>
>>>>>> It would.  In the meantime, though, I've checked in the two-line change to add .buffer in.  ;-)
>>>>>
>>>>> So does that mean PEP 3333 can be accepted now?
>>>>
>>>> TBH I've totally lost track. Hopefully PJE and Graham can tell you...
>>>>
>>>> --
>>>> --Guido van Rossum (python.org/~guido)
>>>>
>>>
>>
>