[Web-SIG] Is PEP 3333 the final solution for WSGI on Python 3?

[Graham Dumpleton]

On 22 October 2010 11:16, P.J. Eby <pje at telecommunity.com> wrote:
> At 10:35 AM 10/22/2010 +1100, Graham Dumpleton wrote:
>>
>> Any one care to comment on my blog post?
>>
>>
>>
>> http://blog.dscpl.com.au/2010/10/is-pep-3333-final-solution-for-wsgi-on.html
>>
>> As far as web framework developers commenting, Armin at:
>>
>>
>>
>> http://www.reddit.com/r/Python/comments/du7bf/is_pep_3333_the_final_solution_for_wsgi_on_python/
>>
>> has said:
>>
>>  """Hopefully not. WSGI could do better and there is a proposal for
>> that (444)."""
>>
>> So, looks he is very cool on the idea.
>>
>> No other developers of actual web frameworks has commented at all on
>> PEP 3333 from what I can see.
>>
>> Graham
>
> Just out of curiosity, Graham, isn't PEP 3333 basically only a slight
> modification to what you yourself proposed and implemented in mod_wsgi for
> Python 3?

Correct, it is a bit more strict and changes wsgi.version back to 1.0.
So, except for wsgi.version, Apache/mod_wsgi already technically
conforms to it. I will be stepping a bit outside of the specification
and having non CGI variables in environment from Apache configuration
be treated as UTF-8 +surrogateescape however, with means to override
the encoding. This though is going to be necessary because of
capabilities of Apache and not an issue with WSGI specification.

> My guess is that there's been no comment because there's really not much to
> say about it.  The most controversial thing about it was Python-Dev's
> objection to modifying PEP 333 in place -- and that's the *only* reason why
> it's a new PEP at all.

I am not sure that it is that simple and that it is a done deal. Some
people have been quite passionate about having bytes used in more
places and the near silence from those people has me concerned that
all is going to happen is that they will ignore PEP 3333 and another
discussion will just erupt again later. It will be quite disappointing
if Armin especially takes that stance and will not support PEP 3333 in
Werkzeug, skip it and seek out an alternative.

As I say in my blog post, ultimately it may not matter as PEP 3333
continues the WSGI name and so if they don't like it then what they
come up with will have to be under a different name else it will be
too confusing. At this point I can't see a future version based on PEP
444 being called WSGI 2.0, it is just going to be better to be clearly
distinct in name after all that has gone on before.

As such, Apache/mod_wsgi can be made to align with PEP 3333 for Python
3 and if anything else comes along later under a different name, then
Apache/mod_wsgi will simply not implement it since it is specific to
WSGI. If people want to somehow use Apache/mod_wsgi for it, they will
have to use an adapter, if possible. Otherwise people will have to
rely on other hosting mechanisms, be those other existing ones where
author is prepared to support any new interface and not so fussy about
naming inconsistencies or anything new that may come along.

Thus I am just after some acknowledgement from involved parties that
it is accepted that PEP 3333 is the way forward for WSGI for Python 3
and that it isn't just going to be ignored. Without that, as far as I
am concerned we are still in limbo with only a little bit more mandate
than before because of you having created the update as new PEP 3333,
yet with no one pledging to accept it and use it going forward for
major web frameworks.

FWIW, what is the normal process for getting a PEP accepted as being
the way of doing things so people all agree? Note that I haven't been
reading python-dev list, so maybe there was some sort of agreement
already expressed there which means PEP 3333 already has some sort of
mandate and people just have to accept it, don't know.

Graham