On 7 January 2011 17:22, Graham Dumpleton <graham.dumple...@gmail.com> wrote:
> On 7 January 2011 17:13, Graham Dumpleton <graham.dumple...@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.dumple...@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 <gu...@python.org> wrote:
>>>> On Thu, Jan 6, 2011 at 9:47 PM, James Y Knight <f...@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)
>>>>
>>>
>>
>
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
