[Web-SIG] WSGI for Python 3

[P.J. Eby]

At 02:37 PM 8/30/2010 +1000, Graham Dumpleton wrote:
>Anyway, rather than keep arguing the point and move forward, let us
>perhaps start now with the following definitions and new names to
>identify them. We can even go a bit stupid and give each its own code
>name so they are in part more memorable. Any next option based on your
>suggestions about changing the WHEAT option can be called MAIZE. And
>if you thinking I am going stark raving mad and should be put in a
>white jacket and locked up, you could well be right. I am not a happy
>camper right now, but that is because of many things besides this WSGI
>stuff. :-)
>
>  And yes I know about the page that has been just recently put up at:
>
>   http://www.wsgi.org/wsgi/Python_3
>
> From memory when I first read it I wasn't sure if that it was
>completely accurate, but at least it doesn't now mention mod_python
>instead of mod_wsgi which was mighty confusing. We can perhaps merge
>the following into that page, ie., expand the table, and talk more
>about the abstract definitions rather than linking it to specific
>implementations at this point. We can perhaps then start capturing the
>pros and cons against each option in the page rather than loosing them
>in the email chain.

I've added a column to the page called "flat" that captures my 
current proposal (native keys, surrogateescape values, byte stream 
in, strict bytes-only for all outputs).  This seems to me an optimum 
balance between:

* Verifiability (especially *composable* verifiability)
* Low cognitive overhead (i.e., fewest things to remember)
* Low amount of finger-typing and fewer conversions

But I certainly could be convinced otherwise by example or argument.

(One other thing I consider a plus for this approach, btw: os.environ 
is still largely usable as a WSGI environ in the CGI case.  This 
isn't so much a valuable thing in itself, as that it's an indicator 
of low complexity and cognitive overhead.)