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

Graham Dumpleton graham.dumpleton at gmail.com
Fri Jan 7 07:22:18 CET 2011


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.

> 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)
>>>
>>
>


More information about the Web-SIG mailing list