[Web-SIG] PEP 444 (aka Web3)

[Chris McDonough]

On Thu, 2010-09-16 at 12:01 -0500, Ian Bicking wrote:
> Well, reiterating some things I've said before:
> 
> * This is clearly just WSGI slightly reworked, why the new name?

The PEP says "Web3 is clearly a WSGI derivative; it only uses a
different name than "WSGI" in order to indicate that it is not in any
way backwards compatible."

I don't really care what the name is.  My experience in various
communities suggests that naming the new totally-bw-incompat thing the
same as the old thing weakens both the new thing and the old thing,
but.. whatever.  I just don't care much.

> * 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.

I'm sorry you're annoyed.  I chose bytes here mainly out of ignorance
and fear. This is an extremely low level protocol, and I just literally
don't know how we can sanely convert environ values to Unicode without
some loss of control or potential for incorrect decoding without having
server encoding configuration.  You say it's easy and straightforward,
and that's fine.  I just haven't internalized enough specification to
know.

I'd very much encourage folks who want to use native strings to create
another PEP: it's just a lot easier to argue about one "thing" than it
is to argue endlessly in snippets on blogs and epic maillist threads.  I
could care less if this *particular* PEP is selected, to be honest.
Let's just get it over within a process where there's at least some
chance of resolution.

> * 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.

Sounds good.

> * 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.

Others have said same, also good.

> * 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.

OK.

- C