[Web-SIG] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

[Ian Bicking]

On Tue, Sep 21, 2010 at 1:17 PM, P.J. Eby <pje at telecommunity.com> wrote:

> [trimming reply headers to just web-sig]
>
> At 12:57 PM 9/21/2010 -0400, Ian Bicking wrote:
>
>  On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby <<mailto:pje at telecommunity.com
>> >pje at telecommunity.com> wrote:
>> The Python 3 specific changes are to use:
>>
>> * ``bytes`` for I/O streams in both directions
>> * ``str`` for environ keys and values
>> * ``bytes`` for arguments to start_response() and write()
>>
>>
>> This is the only thing that seems odd to me -- it seems like the response
>> should be symmetric with the request, and the request in this case uses str
>> for headers (status being header-like), and bytes for the body.
>>
>
> Are you suggesting a "``str`` for headers, ``bytes`` for bodies" approach
> instead?
>

Yes.

I suppose that could work; I was going for "str in, bytes out".  My
> assumption, though, was that headers are relatively easy to address at a
> choke point from a framework's output.  But I guess that iterator output is
> equally chokable.
>

The request body would still be bytes in either model (at least, I assumed
that).

I'm open to discussion on this point, so long as every value produced or
> consumed by a WSGI application is of a specified single type().
>
>
>
>  Otherwise this seems good to me, the only other major errata I can think
>> of are all listed in the links you included.
>>
>
> Um, if by "links" you mean, "included textually in the proposal", then
> sure.  If it's not in the proposal, it's not going in the PEP, even if it's
> on the WSGI Amendments page or Graham's blog.
>

Well, at a minimum there is the size hint on wsgi.input.  Things like
CONTENT_LENGTH are probably more involved than is necessary for this
revision.


-- 
Ian Bicking  |  http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20100921/09a7a0e2/attachment-0001.html>