[Web-SIG] PEP 444 (aka Web3)

[Guido van Rossum]

On Thu, Sep 16, 2010 at 10:01 AM, Ian Bicking <ianb at colorstudy.com> wrote:
> Well, reiterating some things I've said before:
>
> * This is clearly just WSGI slightly reworked, why the new name?
> * Why byte values in the environ?  No one has offered any real reason they
> are better than native strings.  I keep asking people to offer a reason,
> *and no one ever does*.  It's just hyperbole and distraction.  Frankly I'm
> feeling annoyed.  So far my experience makes me believe using native strings
> will make it easier to port and support libraries across 2 and 3.

Hm. IIUC the proposal is to implicitly assume Latin1 when decoding the
bytes to Unicode. I worry that this will just perpetuate mojibake and
other atrocities committed in Python 2.

> * It makes sense to me that the error stream should accept both bytes and
> unicode, and should do a best effort to handle either.  Getting encoding
> errors or type errors when logging an error is very distracting.

This agree on. In logs, mojibake is better than an exception. For me,
hex escapes are probably better than mojibake, but not everyone
agrees.

> * Instead of focusing on Response(*response_tuple), I'd rather just rely on
> something like Response.from_wsgi(response_tuple).  Body first feels very
> unnatural.
> * Regarding long response headers, I think we should ignore the HTTP spec.
> You can put 4k in a Set-Cookie header, such headers aren't easily or safely
> folded... I think the line length constraint in the HTTP spec isn't a
> constraint we need to pay attention to.

No comments on the rest except to note that at this point it looks
unlikely that we can make everyone happy (or even get an agreement to
adopt what would be the long-term technically optimal solution --
AFAICT there is no agreement on what that solution would be, if one
weren't to take porting Python 2 code into account). IOW
something/sokebody has gotta give.

-- 
--Guido van Rossum (python.org/~guido)