Is PEP 3333 the final solution for WSGI on Python 3?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Is PEP 3333 the final solution for WSGI on Python 3?

Graham Dumpleton-2
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
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

PJ Eby
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?

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.

(Indeed, I originally just made the discussed amendments to PEP 333,
and specifically wanted to avoid having a new PEP number in order to
create unnecessary additional discussion or questions.)

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

Graham Dumpleton-2
On 22 October 2010 11:16, P.J. Eby <[hidden email]> 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
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

Jacob Kaplan-Moss-2
In reply to this post by Graham Dumpleton-2
On Thu, Oct 21, 2010 at 6:35 PM, Graham Dumpleton
<[hidden email]> wrote:
> No other developers of actual web frameworks has commented at all on
> PEP 3333 from what I can see.

I wrote a bunch about WSGI/Py3 on python-dev:

http://mail.python.org/pipermail/python-dev/2010-September/103674.html
http://mail.python.org/pipermail/python-dev/2010-September/103717.html
http://mail.python.org/pipermail/python-dev/2010-September/103744.html
http://mail.python.org/pipermail/python-dev/2010-September/103887.html

My feelings haven't changed: deploying Python 2 is awesome. Deploying
Python 3 is impossible. To quote at length from myself:

"""

Deploying web apps under Python 2 right now is actually pretty
awesome. There's a clear leader in mod_wsgi that's fast, stable, easy
to use, and under active development. There's a few great lightweight
pure-Python servers, some new-hotness (Gunicorn) and some
tried-and-true (CherryPy). There's a fast-as-hell bleeding-edge option
(nginx + uwsgi). And those are just the ones I've successfully put
into production -- there're still *more* options if one of those won't
cut it.

The key here is that switching between all of these deployment
situations is *incredibly* easy. [...]

Python 3 offers me none of this. I don't have a wide variety of tools
to choose from. Worse, I don't even have a guarantee of
interoperability between the tools that *do* exist.
"""

The reason I'm not chiming on on 3333 vs 444 is that I DON'T CARE.
Just give me something that works on Python 3, dammit.

I can't even begin to think about moving to Python 3 until I've got a
solid standard with multiple implementations. It seems to me that PEP
3333 could land faster than PEP 444, but if that's not true, again, I
don't care. I just want a deployment answer for Python 3.

I'm sorry if I sound petulant here, but I'm really quite frustrated. I
want to be moving to Python 3 a couple of years ago, and I just don't
understand the issues and problems in WSGI and web servers to be able
to help out. If I was smart enough, I'd help. Instead, I'm trying to
use the bully pulpit any way I can. Please, people, move this damn
thing forward.

Jacob
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

Chris McDonough
In reply to this post by Graham Dumpleton-2
For what it's worth, I'm happy with the changes made to WSGI 1 that
produced PEP 3333.

I'm unlikely to champion PEP 444 going forward.  It has already served
its primary duty to me personally (which was to catalyze the
formalization of some specification that is Python 3 inclusive).

However, Armin may feel differently about it, so this doesn't constitute
a withdrawal of PEP 444.  I'm instead just signaling my own personal
attitude: "don't really care as much now that there's something out
there".

On Fri, 2010-10-22 at 10:35 +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
> _______________________________________________
> Web-SIG mailing list
> [hidden email]
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/chrism%40plope.com
>


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

Armin Ronacher
In reply to this post by Graham Dumpleton-2
Hi,

On 10/22/10 2:35 AM, Graham Dumpleton wrote:
> has said:
>
>    """Hopefully not. WSGI could do better and there is a proposal for
> that (444)."""
Just to give this some more context: I think WSGI (even in Python 2) is
faulty and we have the possibility now to fix it.  Nobody in the web
community is really eager to use Python 3 currently as far as I can see,
so we have some extra time where we can actually introduce some value in
to web development on Python 3.  An improved WSGI specification could be
a key to that.

If PEP 3333 is what we end up with, that is fine with me as well.


Regards,
Armin
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

PJ Eby
At 02:26 PM 10/23/2010 +0300, Armin Ronacher wrote:

>Hi,
>
>On 10/22/10 2:35 AM, Graham Dumpleton wrote:
>>has said:
>>
>>    """Hopefully not. WSGI could do better and there is a proposal for
>>that (444)."""
>Just to give this some more context: I think WSGI (even in Python 2)
>is faulty and we have the possibility now to fix it.  Nobody in the
>web community is really eager to use Python 3 currently as far as I
>can see, so we have some extra time where we can actually introduce
>some value in to web development on Python 3.  An improved WSGI
>specification could be a key to that.
>
>If PEP 3333 is what we end up with, that is fine with me as well.

I don't think it's an either-or case.  PEP 3333 just means that
there's a clear path to port WSGI 1 apps.  If somebody wants to
champion a WSGI 1.1, a 2.0, and whatever else, that's great!

I'm really trying to step *down* from involvement in this; the only
reason I stepped up to do this now is because of the pending 3.2
release and the open question(s) over stdlib APIs that have to
stabilize in this release.

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

Deron Meranda
On Sat, Oct 23, 2010 at 12:43 PM, P.J. Eby <[hidden email]> wrote:
> I don't think it's an either-or case.  PEP 3333 just means that there's a
> clear path to port WSGI 1 apps.  If somebody wants to champion a WSGI 1.1, a
> 2.0, and whatever else, that's great!

I agree, I think PEP 3333 is fine in its scope, it just makes WSGI 1
clearer and gives
a practical and usable path for Python 3 migration.

A newer protocol, whether that's 444 or something else, should then remain a
separate effort, and there's no urgent need to rush that now just so we can
get Python 3 support. Also we should be keeping closer tabs on how the
HTTPbis efforts at the IETF are doing, as a newer replacement protocol
should definitely be coherent with that.

In the mean time, I'd like to see the draft 444 updated soon to better
reflect it's
base on 3333 rather than 333.

--
Deron Meranda
http://deron.meranda.us/
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

Armin Ronacher
In reply to this post by PJ Eby
Hi,

On 10/23/10 7:43 PM, P.J. Eby wrote:
> I don't think it's an either-or case. PEP 3333 just means that there's a
> clear path to port WSGI 1 apps. If somebody wants to champion a WSGI
> 1.1, a 2.0, and whatever else, that's great!
Oh, I was not denying that.  The original post on reddit to which I
commented was called "Is PEP 3333 the final solution for WSGI on Python
3" :)

> I'm really trying to step *down* from involvement in this; the only
> reason I stepped up to do this now is because of the pending 3.2 release
> and the open question(s) over stdlib APIs that have to stabilize in this
> release.
I think the main problem is that we are all incredible happy with Python
2 currently and Python 3 is not very convincing at the moment.  Unleaden
Swallow also did not exactly deliver to it's promises lately, but PyPy
seems to be doing quite well lately, and due to it's nature it would be
unrealistic to assume it switches to Python 3 anytime soon.  (It's one
of the largest Python 2 codebases)

I have to admit that my interest in Python 3 is not very high and I am
most likely not the most reliable person when it comes to driving PEP 444 :)


Regards,
Armin
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

Chris McDonough
On Sun, 2010-10-24 at 10:17 +0300, Armin Ronacher wrote:

> I have to admit that my interest in Python 3 is not very high and I am
> most likely not the most reliable person when it comes to driving PEP 444 :)

We should probably withdraw the PEP, then (unless someone else wants to
step up and champion it), because neither am I.

- C


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

Georg Brandl-2
Am 24.10.2010 16:40, schrieb Chris McDonough:
> On Sun, 2010-10-24 at 10:17 +0300, Armin Ronacher wrote:
>
>> I have to admit that my interest in Python 3 is not very high and I am
>> most likely not the most reliable person when it comes to driving PEP 444 :)
>
> We should probably withdraw the PEP, then (unless someone else wants to
> step up and champion it), because neither am I.

Don't give it up yet -- Deferring is probably the better option.

Georg

--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

Chris McDonough
On Sun, 2010-10-24 at 17:16 +0200, Georg Brandl wrote:

> Am 24.10.2010 16:40, schrieb Chris McDonough:
> > On Sun, 2010-10-24 at 10:17 +0300, Armin Ronacher wrote:
> >
> >> I have to admit that my interest in Python 3 is not very high and I am
> >> most likely not the most reliable person when it comes to driving PEP 444 :)
> >
> > We should probably withdraw the PEP, then (unless someone else wants to
> > step up and champion it), because neither am I.
>
> Don't give it up yet -- Deferring is probably the better option.

TBH, unless someone has immediate interest in championing it, I'd rather
just withdraw it and let someone else resubmit it (or something like it)
later if they want.  It's just going to cause confusion if it's left in
a zombie state without a champion.

- C


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

Georg Brandl-2
Am 24.10.2010 17:58, schrieb Chris McDonough:

> On Sun, 2010-10-24 at 17:16 +0200, Georg Brandl wrote:
>> Am 24.10.2010 16:40, schrieb Chris McDonough:
>> > On Sun, 2010-10-24 at 10:17 +0300, Armin Ronacher wrote:
>> >
>> >> I have to admit that my interest in Python 3 is not very high and I am
>> >> most likely not the most reliable person when it comes to driving PEP 444 :)
>> >
>> > We should probably withdraw the PEP, then (unless someone else wants to
>> > step up and champion it), because neither am I.
>>
>> Don't give it up yet -- Deferring is probably the better option.
>
> TBH, unless someone has immediate interest in championing it, I'd rather
> just withdraw it and let someone else resubmit it (or something like it)
> later if they want.  It's just going to cause confusion if it's left in
> a zombie state without a champion.

Ah, but Deferred is an official state, and describes quite clearly what
state it is in -- not obsolete, but without an active champion.

Georg

--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

Guido van Rossum
On Sun, Oct 24, 2010 at 10:17 AM, Georg Brandl <[hidden email]> wrote:

> Am 24.10.2010 17:58, schrieb Chris McDonough:
>> On Sun, 2010-10-24 at 17:16 +0200, Georg Brandl wrote:
>>> Am 24.10.2010 16:40, schrieb Chris McDonough:
>>> > On Sun, 2010-10-24 at 10:17 +0300, Armin Ronacher wrote:
>>> >
>>> >> I have to admit that my interest in Python 3 is not very high and I am
>>> >> most likely not the most reliable person when it comes to driving PEP 444 :)
>>> >
>>> > We should probably withdraw the PEP, then (unless someone else wants to
>>> > step up and champion it), because neither am I.
>>>
>>> Don't give it up yet -- Deferring is probably the better option.
>>
>> TBH, unless someone has immediate interest in championing it, I'd rather
>> just withdraw it and let someone else resubmit it (or something like it)
>> later if they want.  It's just going to cause confusion if it's left in
>> a zombie state without a champion.
>
> Ah, but Deferred is an official state, and describes quite clearly what
> state it is in -- not obsolete, but without an active champion.

And here I thought for a second you were changing the topic to Twisted. :-)

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Is PEP 3333 the final solution for WSGI on Python 3?

Georg Brandl-2
Am 24.10.2010 19:25, schrieb Guido van Rossum:

> On Sun, Oct 24, 2010 at 10:17 AM, Georg Brandl <[hidden email]> wrote:
>> Am 24.10.2010 17:58, schrieb Chris McDonough:
>>> On Sun, 2010-10-24 at 17:16 +0200, Georg Brandl wrote:
>>>> Am 24.10.2010 16:40, schrieb Chris McDonough:
>>>> > On Sun, 2010-10-24 at 10:17 +0300, Armin Ronacher wrote:
>>>> >
>>>> >> I have to admit that my interest in Python 3 is not very high and I am
>>>> >> most likely not the most reliable person when it comes to driving PEP 444 :)
>>>> >
>>>> > We should probably withdraw the PEP, then (unless someone else wants to
>>>> > step up and champion it), because neither am I.
>>>>
>>>> Don't give it up yet -- Deferring is probably the better option.
>>>
>>> TBH, unless someone has immediate interest in championing it, I'd rather
>>> just withdraw it and let someone else resubmit it (or something like it)
>>> later if they want.  It's just going to cause confusion if it's left in
>>> a zombie state without a champion.
>>
>> Ah, but Deferred is an official state, and describes quite clearly what
>> state it is in -- not obsolete, but without an active champion.
>
> And here I thought for a second you were changing the topic to Twisted. :-)

It's about time to add Twisted to the standard library anyway!!1

Georg

--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com