[Web-SIG] PEP 444 (aka Web3)

[Ian Bicking]

On Thu, Sep 16, 2010 at 4:58 PM, Armin Ronacher <armin.ronacher at active-4.com
> wrote:

> - Bytes values in the environment:
>
>  HTTP transmits bytes, that's a fact we can't change.  When we go
>  with native strings we will go with unicode on 3.x  This has the
>  following implications:
>
>  - getting the right path info requires a decode + an encode
>    unless you are assuming latin1.
>

Not if you are working with the URL-encoded paths.


>  - same as above for the script name and cookie header
>

Cookie is weird.  If that one header could be bytes, that'd be great... but
special-casing Cookie/Set-Cookie is too hard/weird.

Plus handling Cookie/Set-Cookie as Latin1 is just one more line of code
(well, two, one for each header).

 When going with unicode strings on 3.x for environ values, we would
>  have to do the same for outgoing values which makes middlewares a lot
>  harder to write:
>

All response headers handle encoded URLs (e.g., Location), so
SCRIPT_NAME/PATH_INFO issues don't come into play.  Set-Cookie could be an
issue, though only really when someone wants to replicate an external
system's weird cookies -- except for legacy issues it's best for application
developers to stick to ASCII cookies (URL-encoding cookie values is a
popular way of doing this).

I don't know of any other header (or the status) that would reasonably cause
a problem.  And I'm not glossing over corner cases -- I'm generally very
aware and concerned with legacy issues, and interacting with legacy
systems.  There just aren't any here except for the resolvable issues I've
listed.

- web3.errors
>
>  I think Ian raised concern that it's specified to support unicode
>  only.  I don't think we should change that to accepting either bytes
>  or unicode is a good idea on Python 3 where there is no stream in
>  the language or standard library that accepts both at the same time.
>  An implementation for 2.x could support both, but I don't know if
>  there is a usecase for that.  In general though I have to say that
>  very few people use wsgi.errors currently, so I don't think this is
>  a real issue anyways.
>

It's more of an issue under Python 2, it could probably be ignored with
Python 3.  Under Python 2 when you have some error condition it's really
frustrating to encounter some unicode error with the logging of that error
(often covering up the original error).


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