PEP 444 != WSGI 2.0

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

PEP 444 != WSGI 2.0

Graham Dumpleton-2
Can we please clear up a matter.

GothAlice (don't know off hand there real name), keeps going around
and claiming:

"""
After some discussion on the Web-SIG mailing list, PEP 444 is now
"officially" WSGI 2, and PEP 3333 is WSGI 1.1
"""

In this instance on web.py forum on Google Groups.

I have pointed out a couple of times to them that there is no way that
PEP 444 has been blessed as being the official WSGI 2.0 but they are
not listening and are still repeating this claim. They can't also get
right that PEP 3333 clearly says it is still WSGI 1.0 and not WSGI
1.1.

If the people here who's opinion matters are quite happy for GothAlice
to hijack the WSGI 2.0 moniker for PEP 444 I will shut up. But if that
happens, I will voice my objections by simply not having anything to
do with WSGI 2.0 any more.

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: PEP 444 != WSGI 2.0

Graham Dumpleton-2
On 2 January 2011 12:09, Jonas Galvez <[hidden email]> wrote:

> Graham Dumpleton wrote:
>> If the people here who's opinion matters are quite happy for GothAlice
>> to hijack the WSGI 2.0 moniker for PEP 444 I will shut up. But if that
>> happens, I will voice my objections by simply not having anything to
>> do with WSGI 2.0 any more.
>
> Hi Graham, I'm interested in learning what is your motivation for
> objecting that PEP 444 be WSGI 2.0. I'm assuming you must have already
> voiced your criticism on a technical level somewhere by this point.
> Can you point me to it?

Because for all we know right now what will be WSGI 2.0 may look a lot
different to what PEP 444 is now. Already they have taken the original
PEP 444 that was put out by Chris, and which had never actually been
updated based on feedback on the Python WEB-SIG list to address
perceived shortcomings, and started injecting his own ideas on top of
it without any real consultation with those on the WEB-SIG who have
had a lot of experience with all this stuff.

Thus what he is working on is a very fluid specification that keeps
changing. Ie., it is thus a work in progress, yet the way they talk
about it is if it already is the official WSGI 2.0 specification when
it is still no more than a bunch of ideas of what could be done. I am
thus manly objecting at this point on a matter of process and how they
are portraying what PEP 444 is. The PEP 444 by rights should have been
completely withdrawn and marked as rejected. If they want to carry on
and take PEP 444 and turn it into something else, then give it some
other working name, but where it still isn't labelled as WSGI 2.0.
When they have fleshed it out sufficiently and it has passed review on
the Python WEB-SIG that is fine and then gets put up as a PEP with
some blessing, only then should it notionally be anointed as WSGI 2.0
if the community wants that. Don't do this and all you do is cause
ongoing confusion in the community as to what WSGI 2.0 is given that
the definition of what it may be keeps changing.

I also have a various technical issues with the original WSGI
specification and they aren't being addressed in PEP 444 from what I
have seen so far, as well as having issues with new things in PEP 444.
I have blogged and posted on the WEB-SIG list about a number of them
and am now starting to get back into documenting what some of those
other issues are. Overall though, I believe a big step needs to be
taken back and fresh look at this stuff needs to be made. It needs to
be cast into the greater context of how we deploy this stuff as well,
otherwise deployment is going to continue to be a PITA with all the
systems using different ways when there could be a better level of
compatibility across them all to make deployment easier.

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: PEP 444 != WSGI 2.0

ianb
In reply to this post by Graham Dumpleton-2
Until the PEP is approved, it's just a suggestion.  So for it to "really" be WSGI 2 it will have to go through at least some approval process; which is kind of ad hoc, but not so ad hoc as just to implicitly happen.  For WSGI 2 to happen, someone has to write something up and propose it.  Alice has agreed to do that, working from PEP 444 which several other people have participated in.  Calling it "WSGI 2" instead of "Web 3" was brought up on this list, and the general consensus seemed to be that it made sense -- some people felt a little funny about it, but ultimately it seemed to be something everyone was okay with (with some people like myself feeling strongly it should be "WSGI 2").

I'm not sure why you are so stressed out about this?  If you think it's really an issue, perhaps 2 could be replaced with "2alpha" until such time as it is approved?


On Sat, Jan 1, 2011 at 8:02 PM, Graham Dumpleton <[hidden email]> wrote:
Can we please clear up a matter.

GothAlice (don't know off hand there real name), keeps going around
and claiming:

"""
After some discussion on the Web-SIG mailing list, PEP 444 is now
"officially" WSGI 2, and PEP 3333 is WSGI 1.1
"""

In this instance on web.py forum on Google Groups.

I have pointed out a couple of times to them that there is no way that
PEP 444 has been blessed as being the official WSGI 2.0 but they are
not listening and are still repeating this claim. They can't also get
right that PEP 3333 clearly says it is still WSGI 1.0 and not WSGI
1.1.

If the people here who's opinion matters are quite happy for GothAlice
to hijack the WSGI 2.0 moniker for PEP 444 I will shut up. But if that
happens, I will voice my objections by simply not having anything to
do with WSGI 2.0 any more.

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/ianb%40colorstudy.com



--
Ian Bicking  |  http://blog.ianbicking.org

_______________________________________________
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: PEP 444 != WSGI 2.0

Guido van Rossum
On Sat, Jan 1, 2011 at 5:02 PM, Graham Dumpleton
<[hidden email]> wrote:
> Can we please clear up a matter.
>
> GothAlice (don't know off hand there real name), keeps going around
> and claiming:
>
> """
> After some discussion on the Web-SIG mailing list, PEP 444 is now
> "officially" WSGI 2, and PEP 3333 is WSGI 1.1
> """
[...]

>From past posts here, that's Alice Bevan–McGregor
<[hidden email]>, added to the thread.

On Sat, Jan 1, 2011 at 8:34 PM, Ian Bicking <[hidden email]> wrote:

> Until the PEP is approved, it's just a suggestion.  So for it to "really" be
> WSGI 2 it will have to go through at least some approval process; which is
> kind of ad hoc, but not so ad hoc as just to implicitly happen.  For WSGI 2
> to happen, someone has to write something up and propose it.  Alice has
> agreed to do that, working from PEP 444 which several other people have
> participated in.  Calling it "WSGI 2" instead of "Web 3" was brought up on
> this list, and the general consensus seemed to be that it made sense -- some
> people felt a little funny about it, but ultimately it seemed to be
> something everyone was okay with (with some people like myself feeling
> strongly it should be "WSGI 2").
>
> I'm not sure why you are so stressed out about this?  If you think it's
> really an issue, perhaps 2 could be replaced with "2alpha" until such time
> as it is approved?

I'm guessing that Graham is concerned that Alice's assertion implies
that the PEP is approved. IOW that the *future* WSGI 2.0 is equal to
the *current* PEP 444. While we don't know for sure, this is likely
wrong (at least in some details).

OTOH I agree with Ian that it seems correct to say that PEP 444 (which
is still under development) is striving to arrive at a consensus for
what will be named WSGI 2.0. This is not unusual in the world of
standards -- future standards usually are given names and document IDs
long before there is agreement on the contents of the standard. In
this sense Alice's use of "officially" is not incorrect, although out
of context it could be misunderstood to imply PEP approval. I would
recommend adding caution about this whenever the equivalency between
PEP 444 and WSGI 2.0 is mentioned -- perhaps it is enough to state
that "PEP 444 is the draft for WSGI 2.0".

Often people or companies draw premature conclusions from draft
standards and prepare implementations that comply with the draft
standard in the hope that the draft won't change before it is set in
stone, and sometimes such implementations are incorrectly billed as
compliant with the standard (rather than with a specific version of
the draft). I don't know if that is what Alice is doing -- an equally
likely theory is that she's just excited.

I haven't followed the development of PEP 4444 much, so I can't
comment on how much agreement there is on the draft; Ian's use of
"alpha" suggests that there's some way to go still.

One clearly factual error in Alice's (quoted) post: PEP 3333 is WSGI
1.0.1, not WSGI 1.1. AFAIK there's no such thing as WSGI 1.1 now.

Alice, since you have in the past posted here suggesting you are
interested in carrying PEP 444 / WSGI 2.0 forward, please acknowledge
that you understand the concerns raised in this thread.

Graham, I suggest that you don't worry about this issue, and instead
focus on helping the draft turn into a standard by providing feedback
on PEP 444. Unless there's part of the story you're not telling here.

--
--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: PEP 444 != WSGI 2.0

Graham Dumpleton-2
In reply to this post by ianb
On 2 January 2011 15:34, Ian Bicking <[hidden email]> wrote:
> Until the PEP is approved, it's just a suggestion.  So for it to "really" be
> WSGI 2 it will have to go through at least some approval process; which is
> kind of ad hoc, but not so ad hoc as just to implicitly happen.  For WSGI 2
> to happen, someone has to write something up and propose it.  Alice has
> agreed to do that, working from PEP 444 which several other people have
> participated in.  Calling it "WSGI 2" instead of "Web 3" was brought up on
> this list, and the general consensus seemed to be that it made sense

Only about 2 or 3 people commented directly on it from what I
recollect. I would hardly say that is consensus. For myself it came at
a really bad time, coming off the back of a one month trip and
finishing up in a job after 8 1/2 years. If I had known that this
would lead to Alice going around and making comments like 'official'
on what is far from being  I would have objected quite strongly at the
time rather than just treating it like yet another one of the
distractions that has kept coming up over the years when dealing with
the WSGI on Python 3 issue.

> -- some
> people felt a little funny about it, but ultimately it seemed to be
> something everyone was okay with (with some people like myself feeling
> strongly it should be "WSGI 2").
>
> I'm not sure why you are so stressed out about this?

You say I am stressed and Alice in private email likes to think I am
bitter. What I am is passionate. The whole WSGI stuff over the last
few years has been handled so badly by the Python web community it is
embarrassing. We can continue this shambles or try and bring some
sanity with this process. As is, what Alice is now working on will
effectively be the 3rd or 4th variation of what WSGI 2.0 should be
depending on how you count it. First off there was PJEs basic
suggestion of dropping start_response and leaving everything else.
Others then pitched in with there wish list for that. Armin worked on
a proposal for a while and then there was PEP 444 which has mutated
again with what Alice is doing. Some of these have been seen by
outsiders as being what WSGI 2.0 will be and there have at times been
hosting mechanisms or frameworks claiming to support what these
proposals described and calling themselves WSGI 2.0. Luckily those
third party packages claiming to support some form of WSGI 2.0 have
never taken off, but either way the risk of confusion is still there.

> If you think it's
> really an issue, perhaps 2 could be replaced with "2alpha" until such time
> as it is approved?

If it is going to be done under the guise of a continually changing
PEP 444, then refer to it as PEP 444, including the environ tag
prefixes being pep444.

By allowing it to claim in some way that it is going to be WSGI 2.0
you are effectively fixing yourself down a course that that can be the
only successor for WSGI 1.0. So, if someone comes up with a much
better solution, they will be forced to call it something completely
different because you are hardly going to be able to go back and say,
sorry, we made a mistake and all you people who genuinely thought you
were coding to what was going to be a WSGI 2.0 are screwed.

Graham

> On Sat, Jan 1, 2011 at 8:02 PM, Graham Dumpleton
> <[hidden email]> wrote:
>>
>> Can we please clear up a matter.
>>
>> GothAlice (don't know off hand there real name), keeps going around
>> and claiming:
>>
>> """
>> After some discussion on the Web-SIG mailing list, PEP 444 is now
>> "officially" WSGI 2, and PEP 3333 is WSGI 1.1
>> """
>>
>> In this instance on web.py forum on Google Groups.
>>
>> I have pointed out a couple of times to them that there is no way that
>> PEP 444 has been blessed as being the official WSGI 2.0 but they are
>> not listening and are still repeating this claim. They can't also get
>> right that PEP 3333 clearly says it is still WSGI 1.0 and not WSGI
>> 1.1.
>>
>> If the people here who's opinion matters are quite happy for GothAlice
>> to hijack the WSGI 2.0 moniker for PEP 444 I will shut up. But if that
>> happens, I will voice my objections by simply not having anything to
>> do with WSGI 2.0 any more.
>>
>> 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/ianb%40colorstudy.com
>
>
>
> --
> Ian Bicking  |  http://blog.ianbicking.org
>
_______________________________________________
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: PEP 444 != WSGI 2.0

Graham Dumpleton-2
In reply to this post by Guido van Rossum
On 2 January 2011 16:28, Guido van Rossum <[hidden email]> wrote:

> On Sat, Jan 1, 2011 at 5:02 PM, Graham Dumpleton
> <[hidden email]> wrote:
>> Can we please clear up a matter.
>>
>> GothAlice (don't know off hand there real name), keeps going around
>> and claiming:
>>
>> """
>> After some discussion on the Web-SIG mailing list, PEP 444 is now
>> "officially" WSGI 2, and PEP 3333 is WSGI 1.1
>> """
> [...]
>
> From past posts here, that's Alice Bevan–McGregor
> <[hidden email]>, added to the thread.
>
> On Sat, Jan 1, 2011 at 8:34 PM, Ian Bicking <[hidden email]> wrote:
>> Until the PEP is approved, it's just a suggestion.  So for it to "really" be
>> WSGI 2 it will have to go through at least some approval process; which is
>> kind of ad hoc, but not so ad hoc as just to implicitly happen.  For WSGI 2
>> to happen, someone has to write something up and propose it.  Alice has
>> agreed to do that, working from PEP 444 which several other people have
>> participated in.  Calling it "WSGI 2" instead of "Web 3" was brought up on
>> this list, and the general consensus seemed to be that it made sense -- some
>> people felt a little funny about it, but ultimately it seemed to be
>> something everyone was okay with (with some people like myself feeling
>> strongly it should be "WSGI 2").
>>
>> I'm not sure why you are so stressed out about this?  If you think it's
>> really an issue, perhaps 2 could be replaced with "2alpha" until such time
>> as it is approved?
>
> I'm guessing that Graham is concerned that Alice's assertion implies
> that the PEP is approved.

I certainly don't take it as being approved because I know that PEP
444 is quite incomplete at this time. It is the perceptions others get
when they are being told that PEP 444 is WSGI 2.0 that I am worried
about.

> IOW that the *future* WSGI 2.0 is equal to
> the *current* PEP 444. While we don't know for sure, this is likely
> wrong (at least in some details).
>
> OTOH I agree with Ian that it seems correct to say that PEP 444 (which
> is still under development) is striving to arrive at a consensus for
> what will be named WSGI 2.0. This is not unusual in the world of
> standards -- future standards usually are given names and document IDs
> long before there is agreement on the contents of the standard. In
> this sense Alice's use of "officially" is not incorrect, although out
> of context it could be misunderstood to imply PEP approval. I would
> recommend adding caution about this whenever the equivalency between
> PEP 444 and WSGI 2.0 is mentioned -- perhaps it is enough to state
> that "PEP 444 is the draft for WSGI 2.0".

I'd suggest that that is even too strong. You are giving the
impression that no one else can separately come up with another
proposal, especially one that is significantly different.

> Often people or companies draw premature conclusions from draft
> standards and prepare implementations that comply with the draft
> standard in the hope that the draft won't change before it is set in
> stone, and sometimes such implementations are incorrectly billed as
> compliant with the standard (rather than with a specific version of
> the draft). I don't know if that is what Alice is doing -- an equally
> likely theory is that she's just excited.
>
> I haven't followed the development of PEP 4444 much, so I can't
> comment on how much agreement there is on the draft; Ian's use of
> "alpha" suggests that there's some way to go still.
>
> One clearly factual error in Alice's (quoted) post: PEP 3333 is WSGI
> 1.0.1, not WSGI 1.1. AFAIK there's no such thing as WSGI 1.1 now.
>
> Alice, since you have in the past posted here suggesting you are
> interested in carrying PEP 444 / WSGI 2.0 forward, please acknowledge
> that you understand the concerns raised in this thread.
>
> Graham, I suggest that you don't worry about this issue, and instead
> focus on helping the draft turn into a standard by providing feedback
> on PEP 444.

That may be too late. Alice and I haven't exactly hit it off well.
Using the #webcore IRC channel as the forum to work on it as Alice
wants is also totally inadequate. IRC is just not a suitable forum for
discussing this. It is just not possible to fit into a few lines what
takes pages to explain to a level that people can understand. As much
as this mailing list has caused seemingly never ending discussions in
the past that go no where, it is still the appropriate forum for any
discussion.

> Unless there's part of the story you're not telling here.

It should be no secret that I have been progressively poking holes in
the existing WSGI specification through my blog posts and suggesting
remedies. Overall I still see what is being done as more of a band aid
solution. The whole thing needs a rethink because even when you patch
some things, the design in some areas is arguably broken, eg.
wsgi.file_wrapper. Just dropping features or ignoring the fact they
are broken isn't the answer though.

There may also be merit in seeing whether the minimum Python version
be increased such that a solution could may use of new language
features added since Python 2.3. In Python 2.3 you couldn't yield in a
try block. You also didn't have the with statement. No one is looking
at how WSGI might be made better by utilising such new features or at
least understanding properly how the existing specification interacts
with them.

Take for example PEP 325 which the close() method for resource
reclamation was based on. That PEP was rejected in the end and was
replaced with PEP 342 which worked quite differently, yet I cant see
that the WSGI specification was revisited in light of how it ended up
being implemented and the implications of that.

As I have said before, I also still believe that any revised
specification needs to take into consideration deployment. Right now
deployment is still a bit of a mess. If standardisation around a
strategy for how you deploy is reached then likely would be a separate
PEP, but you don't want a situation where it still a bit of a fudge
because the base WSGI specification doesn't make it easy and an
opportunity was missed to change it.

So, what am I saying that isn't being heard, only that I don't want to
see a band aid solution. I had hoped to devote a lot more time to all
this in the coming year now that I have changed jobs and have more
flexibility, but am concerned that it is being taken down a specific
path with no ability to change it.

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: PEP 444 != WSGI 2.0

Alice Bevan–McGregor
In reply to this post by Graham Dumpleton-2
Graham,

> GothAlice (don't know off hand there real name), keeps going around and
> claiming:

Alice Zoë Bevan-McGregor.  If the unicode in my newsreader doesn't
work, that's an e with an umlaut.

> I have pointed out a couple of times to them that there is no way that
> PEP 444 has been blessed as being the official WSGI 2.0 but they are
> not listening and are still repeating this claim. They can't also get
> right that PEP 3333 clearly says it is still WSGI 1.0 and not WSGI 1.1.

Interestingly, we're both wrong.  PEP 3333 clearly states it's WSGI
1.0.1 -- it's in the title.  My excuse is 60 hours straight of sleep
depravation over the holidays.  ;)

> Because for all we know right now what will be WSGI 2.0 may look a lot
> different to what PEP 444 is now.

That's not a technical reason against, that's a reason to step in and
help shape the future.

> Already they have taken the original PEP 444 that was put out by Chris,
> and which had never actually been updated based on feedback on the
> Python WEB-SIG list to address perceived shortcomings, and started
> injecting his own ideas on top of it without any real consultation with
> those on the WEB-SIG who have had a lot of experience with all this
> stuff.

I, too, have a fair amount of experience with WSGI, having utilized a
nubmer of alternate frameworks, worked around several common issues,
ripped apart the top 10 HTTP servers to examine their inner workings,
torn apart a framework or two, written a performant HTTP/1.1 server
against both the published PEP 444 draft and my rewrite, and have
written my own framework used on a number of production deployments in
at least four countries.

If you'll pardon the expression, it's not like I'm a random ass-hat off
the street with two weeks of Python experience.

> Thus what he is working on is a very fluid specification that keeps
> changing. Ie., it is thus a work in progress, yet the way they talk
> about it is if it already is the official WSGI 2.0 specification when
> it is still no more than a bunch of ideas of what could be done.

"He" and "they."  Better than "it", I suppose, though last time I
checked I'm not "people". ;P

It's a draft PEP.  Looking at it, it prominently states at the top of
both the published and rewritten versions: draft.  Pretty much any time
I mention my rewrite of it (for clearer RFC-style language and
disambiguation) I either explicitly call it a "draft" or use language
indicative of a work in progress.

> [snip] Don't do this and all you do is cause ongoing confusion in the
> community as to what WSGI 2.0 is given that the definition of what it
> may be keeps changing.

From a comment I made on your blog:

> PEP 3333 is a simple-to-implement organic evolution of PEP 333, and
> thus requires (or should require) little work on the part of the WSGI
> application developer or WSGI server author. PEP 444 is a clean break.

And further elaborated in further comments:

> PEP 3333 can do a lot of good while maintaining gross compatibility
> between Py2K and 3K with the same WSGI1 API across both. Also as stated
> before, PEP 3333 should be ratified As Soon As Possible™. The support
> is there from the developers implementing it, the implementation is a
> refinement of PEP 333 w/ clarifications, and all can be happy.
>
> PEP 444 / WSGI 2 is completely different in goals and approach.

I think it's fairly clear that 3333 is closer to ratification and
simpler to migrate to, and is a clear way forward for the short- to
mid-term.

> I also have a various technical issues with the original WSGI
> specification and they aren't being addressed in PEP 444 from what I
> have seen so far, as well as having issues with new things in PEP 444.

Have you read my draft rewrite? [1] It incorporates solutions to a
number of the problems you have described in various articles on your
blog.  In fact, it's modeled fairly heavily after your "definition 4"
and its use of native strings.

> I have blogged and posted on the WEB-SIG list about a number of them
> and am now starting to get back into documenting what some of those
> other issues are.

I look forward to further input.

> Overall though, I believe a big step needs to be taken back and fresh
> look at this stuff needs to be made.

That was the goal of the rewrite.  PEP 444 / web3 as published on the
Python website does fail to solve a number of problems.

> It needs to be cast into the greater context of how we deploy this
> stuff as well, otherwise deployment is going to continue to be a PITA
> with all the systems using different ways when there could be a better
> level of compatibility across them all to make deployment easier.

Deployment isn't really the domain of the web interface API; we have
distribute, pypi, eggs, etc., etc. for literal package distribution
(including deployment).  I think a separate PEP should be used to
describe, say, entry point-based high-level deployment similar to
PasteDeploy, as an example.

        - Alice

[1] http://bit.ly/e7rtI6


_______________________________________________
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: PEP 444 != WSGI 2.0

Alice Bevan–McGregor
In reply to this post by Graham Dumpleton-2
>>> "After some discussion on the Web-SIG mailing list, PEP 444 is now
>>> "officially" WSGI 2, and PEP 3333 is WSGI 1.1"

This out-of-context quote came after prior discussion of PEP 444 (and
clear statements of draft-ness) throughout a rather excellent thread on
HTTP server performance.

The majority of the quotes I find on the CherryPy and WebPy mailing
lists are better worded: "...updated version of PEP 444[1] is availble
in draft form", "...[m.s.http] supports PEP 444 (with modifications)
and, soon, my draft rewrite" and "...PEP 444, I'm trying as hard as I
can to get my rewrite polished" show up in a quick search.

Apologies for the confusion.

> I'm guessing that Graham is concerned that Alice's assertion implies
> that the PEP is approved.

He has also raised concerns over my fundamentally not having a mandate,
having not been granted control over anything, etc.  For completeness
sake, here's a link to the beginning of the thread in his blog comments:

        http://bit.ly/htHLAz

>> OTOH I agree with Ian that it seems correct to say that PEP 444 (which
>> is still under development) is striving to arrive at a consensus for
>> what will be named WSGI 2.0. This is not unusual in the world of
>> standards -- future standards usually are given names and document IDs
>> long before there is agreement on the contents of the standard. In this
>> sense Alice's use of "officially" is not incorrect, although out of
>> context it could be misunderstood to imply PEP approval. I would
>> recommend adding caution about this whenever the equivalency between
>> PEP 444 and WSGI 2.0 is mentioned -- perhaps it is enough to state that
>> "PEP 444 is the draft for WSGI 2.0".
>
> I'd suggest that that is even too strong. You are giving the impression
> that no one else can separately come up with another proposal,
> especially one that is significantly different.

People have been referring to "anything beyond WSGI 1" as "WSGI 2" for
a long time.  As in, "I'd like to see X in WSGI 2", or "I hope they fix
Y in WSGI 2", etc.

As it stands, and since you have refused to give evidence towards
(links to) others working on things they refer to as "WSGI 2", my
references to PEP 444 as a draft of WSGI 2 are not unreasonable.  
Quotes taken out of context to support your arguments aren't needed.

>> Often people or companies draw premature conclusions from draft
>> standards and prepare implementations that comply with the draft
>> standard in the hope that the draft won't change before it is set in
>> stone, and sometimes such implementations are incorrectly billed as
>> compliant with the standard (rather than with a specific version of the
>> draft). I don't know if that is what Alice is doing -- an equally
>> likely theory is that she's just excited.

Darn tootin' I'm excited.  :D  The only things that depress me in the
slightest are the lack of current discussion on the Web-SIG list (I did
post a thread announcing my rewrite and asking for input, but there
were no takers) and being told (indirectly) that my solution is crap,
it'll never be adopted, that I'm wasting my time, and wasting everybody
else's time.

That's not constructive critisizm or technical faults, that's
attempting to beat someone down with the weight of your opinion.

>> I haven't followed the development of PEP 444 much, so I can't comment
>> on how much agreement there is on the draft; Ian's use of "alpha"
>> suggests that there's some way to go still.

There's a long way to go; I don't expect to see even hints of
ratification in less than 6 months, really.  I have made that clear in
prior discussions.

>> One clearly factual error in Alice's (quoted) post: PEP 3333 is WSGI
>> 1.0.1, not WSGI 1.1. AFAIK there's no such thing as WSGI 1.1 now.

Indeed; apologies for that.  On the mailing lists where Graham has
stepped in and corrected me I've responsed by thanking him and
confirming that 3333 is, in fact, 1.0.1.

>> Alice, since you have in the past posted here suggesting you are
>> interested in carrying PEP 444 / WSGI 2.0 forward, please acknowledge
>> that you understand the concerns raised in this thread.

Guido, I definitely do; and I have attempted to be as careful as I can
when attempting to stir discussion over the future of WSGI on any forum
where I mention it.  I may ocasionally slip up and not give the
appropriately sized warnings, but I do not do so intentionally!

(Up here in the Canadark the government is now mandating 3/4 of the
pack graphic warnings on cigarette packages; surely discussion over a
document which clearly states DRAFT in the header don't need to be
couched in that level of politial correctness!)

I see it as unfortunate, however, that a thread discussing the
validitiy of PEP 444 going forward with the moniker "WSGI 2" using
biased out-of-context quotes has spawned more discussion than the
threads asking for technical input on the spec.

Politics is more juicy than dry techincal documents, it seems.

:(

> That may be too late. Alice and I haven't exactly hit it off well.
> Using the #webcore IRC channel as the forum to work on it as Alice
> wants is also totally inadequate.

I asked you to join me on IRC to better voice your technical complaints
against PEP 444, not to attempt to get into a verbal sparring match.  
IRC is higher fidelity than threads in blog comments and isn't an
unreasonable request after a comment thread begins to visibly derail.

> It is just not possible to fit into a few lines what takes pages to
> explain to a level that people can understand. As much as this mailing
> list has caused seemingly never ending discussions in the past that go
> no where, it is still the appropriate forum for any discussion.

Then please resurrect my "PEP 444 Draft Rewrite" thread from the 24th
of Dec (merry x-mas!) and describe the technical faults you see within
it.  Using the same argument, your blog (and comments system) is a less
desireable place for discussion than this mailing list, too.

> ... Overall I still see what is being done as more of a band aid
> solution. The whole thing needs a rethink because even when you patch
> some things, the design in some areas is arguably broken, eg.
> wsgi.file_wrapper. Just dropping features or ignoring the fact they are
> broken isn't the answer though.
> [snip] ... There may also be merit in seeing whether the minimum Python
> version be increased such that a solution could may use of new language
> features added since Python 2.3. [snip]

Now I'm sure: you haven't read my rewrite.

> So, what am I saying that isn't being heard, only that I don't want to
> see a band aid solution. I had hoped to devote a lot more time to all
> this in the coming year now that I have changed jobs and have more
> flexibility, but am concerned that it is being taken down a specific
> path with no ability to change it.

You are free to write your own PEP and attempt to garner wide-spread
review and adoption.  You are also in a position in which to encourage
adoption by adding support to mod_wsgi, which is a signifigantly more
impressive position to be in than my simply having written a
proof-of-concept HTTP server to test out PEP 444 ideas, no matter how
efficient or light-weight it may be.

        - Alice.


_______________________________________________
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: PEP 444 != WSGI 2.0

PJ Eby
In reply to this post by Graham Dumpleton-2
At 05:04 PM 1/2/2011 +1100, Graham Dumpleton wrote:
>That PEP was rejected in the end and was
>replaced with PEP 342 which worked quite differently, yet I cant see
>that the WSGI specification was revisited in light of how it ended up
>being implemented and the implications of that.

Part of my contribution to PEP 342 was ensuring that it was
sufficiently PEP 325-compatible to ensure that PEP 333 wouldn't
*need* revisiting.  At least, not with respect to generator close()
methods anyway.  ;-)

_______________________________________________
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: PEP 444 != WSGI 2.0

Guido van Rossum
In reply to this post by Alice Bevan–McGregor
Alice and Graham,

I worry a lot that there's a fight brewing here that will lead to disappointment all around. I see accusations, demands, and passion. I also see a lot of apathy in the web-sig. This is not a recipe for a successful standard.

Since it appears we have or are about to face a breakdown of communication, I'd like to start with some remarks on the mechanics of communication.
  • Alice hasn't posted a link to her rewrite of PEP 444 in a while. AFAICT it's this: https://github.com/GothAlice/wsgi2/blob/master/pep444.textile . I find it a bit disturbing that the "official" copy of PEP 444 (http://www.python.org/dev/peps/pep-0444/ ) hasn't been updated. This is confusing for occasional observers (like myself), since the python.org copy looks quite dead. It also is not in line with the PEP workflow as written down in PEP 1 (http://www.python.org/dev/peps/pep-0001/#pep-work-flow ).
  • It is not reasonable to demand a discussion on IRC. In fact I think it is one of the worst media for arriving agreement over a standard. IRC doesn't have public logs for those who didn't participate in real time (apparently intentionally so); it is pretty hostile to people who don't use it regularly (I am one of those); it doesn't work well for people in different timezones. Blog comments are not much better (they are archived, but as a medium they get too much spam and are too scattered to be worth tracking down for other participants); the web-sig mailing list is the preferred forum.
  • If you are going to quote stuff from earlier in the thread and respond to it using "you", please don't strip the attributions (or add them if your mailer doesn't). Also it's best to keep the person you address in the To: line of the message (or add them back if your mailer doesn't automatically do this).
With that out of the way, let me try to analyze the crux of the matter. The WSGI 1.0 standard (PEP 333) has been widely successful, but, like any standard, it has some flaws. People thought that Python 3 would be a good opportunity to fix the flaws. A proposal was drafted, and posted as PEP 444, but no agreement was reached. In order to fix some obvious flaws due to Python 3's different treatment of bytes and text, a much less ambitious update was produced as PEP 3333, and labeled WSGI 1.0.1. Although this is still marked as draft, I personally think of it as accepted; it is really just a very small set of clarifications and disambiguations of PEP 333, specifically for the benefit of interoperability between WSGI 1.0 apps and servers across the Python 2 / Python 3 boundary.

But there still was no WSGI 2.0, and the original PEP 444 authors stopped pushing for their more ambitious draft (I recall this from the web-sig list; the PEP itself was not updated to reflect this). Then Alice came along, with much enthusiasm (though perhaps not enough prior understanding of Python's PEP process) and offered to rewrite PEP 444 to make it better, and to aim to make the updated version the agreed-upon WSGI 2.0 standard.

I can't quite tell what happened from there; IIRC Alice's proposal did not receive much objection but neither did she get much support from the folks on web-sig -- perhaps people were tired of the discussion (which had already gone around once and not reached any agreement), perhaps people were too busy to read the list. It seems Graham, at least, falls in the latter category and is now regretting that he didn't speak up earlier. Ian, OTOH, seems to implicitly endorse Alice's actions, and seems to be hoping that a widely accepted WSGI 2.0 standard will come out of her work.

In the mean time, Alice (understandably) has looked for other forums where she got more feedback -- I may not like IRC, but I can see how the general apathy on the web-sig is not exactly encouraging. (This is a general problem with Python -- we always complain that there aren't enough people to do the work, but when someone shows up and offers to do some work, they don't get much support. On python-dev we've acknowledged this and are trying to get better about it.)

In order to get WSGI 2.0 back on the standards track, I think a number of things have to happen.

First, it would be great if Alice could prepare a version of her draft in the format required for PEPs, and submit it to the PEP editors ([hidden email]). Note that the PEP editors do *not* judge a PEP by its technical merits or have a say in its approval (though they may reject outright nonsense) -- they merely facilitate the discussion by promptly checking in the submitted draft, so that PEP authors don't need SVN (or, soon, I hope Hg) access. The PEP editors also ensure that the PEP is formatted right, so that it can be automatically processed into HTML for publication on python.org, and they may make simple fixes for typos/spelling/grammar. In my experience (being one of them), the PEP editors usually respond within 24 hours, and don't have any problem with frequent submissions, as long as new submissions of the same PEP incorporate any changes that the PEP editors made (e.g. ReST formatting fixes).

(Another way to get new versions submitted to SVN would be to ask the other author of PEP 444, Armin Ronacher, to check it in; he has submit privileges.)

The longer Alice's draft lingers on github, the less likely I think it is that it will ever be elevated to the official WSGI 2.0 standard.

At the same time, I hope that web-sig and Graham can start discussing the technical merits of Alice's proposal, so that Alice can incorporate the feedback into her draft. It is my understanding that Alice primarily offered to improve the writing and precision of the PEP (although that doesn't mean she can't have an opinion on specific features), and that she is open to changes proposed by others. (If I were wrong about this, and Alice had an ax to grind, that would change things, and it might even make sense to have multiple competing proposals, each hopeful to once earn the WSGI 2.0 moniker. But I hope not.)

Alice, I hope you can live with these recommendations. While it may place a burden on you to convert your draft to ReST and to have to maintain it that way, I think there is a much better chance of an open community discussion leading to a widely accepted standard if you start following the PEP rules set out in PEP 1 (and a few other low-numbered PEPs).

Graham, I hope that you can stop being grumpy about the process that is being followed and start using your passion to write up a critique of the technical merits of Alice's draft. You don't have to attack the whole draft at once -- you can start by picking one or two important issues and try to guide a discussion here on web-sig to tease out the best solutions.  Please  understand that given the many different ways people use and implement WSGI there may be no perfect solution within reach -- writing a successful standard is the art of the compromise. (If you still think the process going forward should be different, please write me off-list with your concerns.)

Everyone else on this list, please make a new year's resolution to help the WSGI 2.0 standard become a reality in 2011.

--
--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: PEP 444 != WSGI 2.0

Chris McDonough
On Sun, 2011-01-02 at 09:21 -0800, Guido van Rossum wrote:

> Graham, I hope that you can stop being grumpy about the process that
> is being followed and start using your passion to write up a critique
> of the technical merits of Alice's draft. You don't have to attack the
> whole draft at once -- you can start by picking one or two important
> issues and try to guide a discussion here on web-sig to tease out the
> best solutions.  Please  understand that given the many different ways
> people use and implement WSGI there may be no perfect solution within
> reach -- writing a successful standard is the art of the compromise.
> (If you still think the process going forward should be different,
> please write me off-list with your concerns.)
>
> Everyone else on this list, please make a new year's resolution to
> help the WSGI 2.0 standard become a reality in 2011.

I think Graham mostly has an issue with this thing being called "WSGI
2".

FTR, avoiding naming arguments is why I titled the original PEP "Web3".
I knew that if I didn't (even though personally I couldn't care less if
it was called Buick or McNugget), people would expend effort arguing
about the name rather than concentrate on the process of creating a new
standard.  They did anyway of course; many people argued publically
wishing to rename Web3 to WSGI2.  On balance, though, I think giving the
standard a "neutral" name before it's widely accepted as a WSGI
successor was (and still is) a good idea, if only as a conflict
avoidance strategy. ;-)

That said, I have no opinion on the technical merits of the new PEP 444
draft; I've resigned myself to using derivatives of PEP 3333 "forever".
It's good enough.  Most of the really interesting stuff seems to happen
at higher levels anyway, and the benefit of a new standard doesn't
outweigh the angst caused by trying to reach another compromise.  I'd
suggest we just embrace it, adding minor tweaks as necessary, until we
reach some sort of technical impasse it doesn't address.

- 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: PEP 444 != WSGI 2.0

PJ Eby
In reply to this post by Graham Dumpleton-2
At 01:47 AM 1/2/2011 -0800, Alice Bevan­McGregor wrote:
>The only things that depress me in the slightest are the lack of
>current discussion on the Web-SIG list (I did post a thread
>announcing my rewrite and asking for input, but there were no takers)

FWIW, my lack of interest has been due to two factors.  First, the
original version of PEP 444 before you worked on it was questionable
in my book, due to the addition of new optional features (e.g.
async), and second, when I saw your "filters" proposal, it struck me
as more of the same, and put me off from investigating further.  (The
whole idea of having a WSGI 2 (IMO at least), was to get rid of cruft
and fix bugs, not to add new features.)

Reading the draft now (I had not done so previously), I would suggest
making your filters proposal available as a standalone module (or an
addition to a future version of wsgiref.util), for anybody who wants
that feature, e.g. via:

   def filter_app(app, ingress=(), egress=()):
       def wrapped(environ):
           for f in ingress: f(environ)
           s, h, b = app(environ)
           for f in egress:
               s, h, b = f(environ, s, h, b)
           return s, h, b
       return wrapped

(Writing this implementation highlights one problem with the notion
of filters, though, and that's that egress filters can't trap an
error in the application.)

As far as the rest of the draft is concerned, in order to give
*thorough* technical feedback, I'd need to first make sure that all
of the important rules from 3333 are still present, which is hard to
do without basically printing out both PEPs and doing a line-by-line analysis.

I notice that file_wrapper is missing, for example, but am not clear
on the rationale for its removal.  Is it your intention that servers
wishing to support file iteration should check for a fileno() directly?

There are a number of minor errors in the draft, such as saying that
__iter__ must return a bytes instance (it should return an iterator
yielding bytes instances) and __iter__ itself has broken markup.

On other matters:

* I remain a strong -1 on the .script_name and .path_info variables
(one of which is named incorrectly in the draft), for reasons
outlined here previously.  (Specifically, that environ redundancy is
a train wreck for middleware, which must be written to support both
ways of providing the same variable, or to delete the extended
version when modifying the environment.)

* -1 on the key-specific encoding schemes for the various CGI
variables' values -- for continuity of coding (not to mention
simplicity) PEP 3333's approach to environ encodings should be
used.  (That is, the environ consists of bytes-in-unicode-form,
rather than true unicode strings.)

* +1 to requiring Python 2.6 -- standardizing on b'' notation makes
good sense and improves forward-portability to Python 3.

* Where is the PARAMETERS variable defined in the CGI spec?  What
servers actually support it?

* The language about empty vs. missing environment variables appears
to have disappeared; without it, the spec is ambiguous.

Those are the issues I have identified on a first reading, without
doing a full analysis.  However, in lieu of such an analysis, I would
take Graham's word on whether or not your spec addresses the HTTP
compliance/implementation issues found in previous WSGI specs.

If I may offer a recommendation from previous experience steering
this PEP, I would say that just because other people know (say) HTTP
better than you, doesn't mean that you can't still make a better spec
than they can.  You don't have to make *your* proposal into
*Graham's* spec, or even the spec that Graham would have wanted you
to make.  But you *do* need to take Graham's *goals* into consideration.

During the original drafting of PEP 333, Ian proposed quite a lot of
features that I shot down...  but I modified what I was doing so that
Ian could still achieve his *goals* within the spec, without
compromising my core vision for the spec (which was that it should be
as close to trivial for server implementers as possible, and not
expose any application API that might be perceived by framework
developers as competition).

So, I urge you to pay attention when Graham says something about what
the spec is lacking or how it's broken.  You don't have to fix it
*his* way, but you do need to fix such that he can still get
there.  WSGI really does need some fixes for chunking and streaming,
and Graham absolutely has the expertise in that area, and I would
100% defer to his judgment on whether some proposal of mine got it
right in that area.

That doesn't mean I would just adopt whatever he proposed, though, if
it didn't meet *my* goals.

That's the hart part of making a spec, but it's also the part that
makes one great.

_______________________________________________
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: PEP 444 != WSGI 2.0

Guido van Rossum
In reply to this post by Chris McDonough
On Sun, Jan 2, 2011 at 11:14 AM, Chris McDonough <[hidden email]> wrote:
On Sun, 2011-01-02 at 09:21 -0800, Guido van Rossum wrote:
> Graham, I hope that you can stop being grumpy about the process that
> is being followed and start using your passion to write up a critique
> of the technical merits of Alice's draft. You don't have to attack the
> whole draft at once -- you can start by picking one or two important
> issues and try to guide a discussion here on web-sig to tease out the
> best solutions.  Please  understand that given the many different ways
> people use and implement WSGI there may be no perfect solution within
> reach -- writing a successful standard is the art of the compromise.
> (If you still think the process going forward should be different,
> please write me off-list with your concerns.)
>
> Everyone else on this list, please make a new year's resolution to
> help the WSGI 2.0 standard become a reality in 2011.

I think Graham mostly has an issue with this thing being called "WSGI
2".

FTR, avoiding naming arguments is why I titled the original PEP "Web3".
I knew that if I didn't (even though personally I couldn't care less if
it was called Buick or McNugget), people would expend effort arguing
about the name rather than concentrate on the process of creating a new
standard.  They did anyway of course; many people argued publically
wishing to rename Web3 to WSGI2.  On balance, though, I think giving the
standard a "neutral" name before it's widely accepted as a WSGI
successor was (and still is) a good idea, if only as a conflict
avoidance strategy. ;-)

Well, it seems too late for that now. :-)

Note that a new standard, even with a familiar name, doesn't automatically get wide adoption. This wouldn't be the first time that a new version of a popular standard is put forward by some well-meaning folks, which is subsequently ignored by most users. (IIRC this happened to several versions of IMAP, there's been an "improvement" of HTTP that nobody uses, and HTML 5 seems to be saying that XHTML was a mistake.

So, let's discuss the merits.
 
That said, I have no opinion on the technical merits of the new PEP 444
draft; I've resigned myself to using derivatives of PEP 3333 "forever".
It's good enough.  Most of the really interesting stuff seems to happen
at higher levels anyway, and the benefit of a new standard doesn't
outweigh the angst caused by trying to reach another compromise.  I'd
suggest we just embrace it, adding minor tweaks as necessary, until we
reach some sort of technical impasse it doesn't address.
 
Actually that does sound like an opinion on the technical merits. I can't tell though, because I'm not familiar enough with PEP 444 to know what the critical differences are compared to PEP 3333. Could someone summarize?

--
--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: PEP 444 != WSGI 2.0

Alice Bevan–McGregor
In reply to this post by Guido van Rossum
On 2011-01-02 09:21:29 -0800, Guido van Rossum said:
> Alice hasn't posted a link to her rewrite of PEP 444 in a while. AFAICT
> it's this:
> https://github.com/GothAlice/wsgi2/blob/master/pep444.textile . I find
> it a bit disturbing that the "official" copy of PEP 444
> (http://www.python.org/dev/peps/pep-0444/ ) hasn't been updated. This
> is confusing for occasional observers (like myself), since the
> python.org copy looks quite dead. It also is not in line with the PEP
> workflow as written down in PEP 1
> (http://www.python.org/dev/peps/pep-0001/#pep-work-flow ).

I am unsure of the policy behind updating a PEP on the website from a
partial (with glaring holes) source.  In my rewrite there are several
sections that need to be fleshed out before I would consider pushing it
up-stream.

I'm tentative that way.  ;)

> It is not reasonable to demand a discussion on IRC. In fact I think it
> is one of the worst media for arriving agreement over a standard. IRC
> doesn't have public logs for those who didn't participate in real time
> (apparently intentionally so); it is pretty hostile to people who don't
> use it regularly (I am one of those); it doesn't work well for people
> in different timezones. Blog comments are not much better (they are
> archived, but as a medium they get too much spam and are too scattered
> to be worth tracking down for other participants); the web-sig mailing
> list is the preferred forum.

Understood.

> If you are going to quote stuff from earlier in the thread and respond
> to it using "you", please don't strip the attributions (or add them if
> your mailer doesn't). Also it's best to keep the person you address in
> the To: line of the message (or add them back if your mailer doesn't
> automatically do this).

I do forget that not all newsreaders are the same, and that while mine
may make quoted text relate to the threading of the messages, not all
do.  Apologies.  Unfortunately, I subscribe and post using a Usenet
news reader, so e-mail functionality is not included.  :/

> In order to fix some obvious flaws due to Python 3's different
> treatment of bytes and text, a much less ambitious update was produced
> as PEP 3333, and labeled WSGI 1.0.1. Although this is still marked as
> draft, I personally think of it as accepted; it is really just a very
> small set of clarifications and disambiguations of PEP 333,
> specifically for the benefit of interoperability between WSGI 1.0 apps
> and servers across the Python 2 / Python 3 boundary.

PEP 3333 is an excellent solution that should be quick to adopt.  My
PEP 444 rewrite takes a fundamentally different approach in an attempt
to simplify and solve broader problems than pure compatibility.

> In the mean time, Alice (understandably) has looked for other forums
> where she got more feedback -- I may not like IRC, but I can see how
> the general apathy on the web-sig is not exactly encouraging. (This is
> a general problem with Python -- we always complain that there aren't
> enough people to do the work, but when someone shows up and offers to
> do some work, they don't get much support. On python-dev we've
> acknowledged this and are trying to get better about it.)

I have recieved valuable input from a co-conspirator on IRC (who is on
the other side of the world from me) and mentioning PEP 444 on other
mailing lists (webpy, cherrypy, pylons) has garnered some interesting
discussion.

> First, it would be great if Alice could prepare a version of her draft
> in the format required for PEPs, and submit it to the PEP editors.

I will make this a priority.

> (If I were wrong about this, and Alice had an ax to grind, that would
> change things, and it might even make sense to have multiple competing
> proposals, each hopeful to once earn the WSGI 2.0 moniker. But I hope
> not.)

Despite being a framework author, I am distinctly attempting to tackle
PEP 444 from an independant viewpoint.  I want a workable solution for
the majority-not nessicarily /everybody/-not something that caters only
for solution A or solution B.  The HTTP/1.1 server I've written is,
ATM, merely a platform from which to brainstorm ideas for PEP 444, and
to check, using code, that 444 is viable.

> Alice, I hope you can live with these recommendations. While it may
> place a burden on you to convert your draft to ReST and to have to
> maintain it that way, I think there is a much better chance of an open
> community discussion leading to a widely accepted standard if you start
> following the PEP rules set out in PEP 1 (and a few other low-numbered
> PEPs).

I'll give the low-numbered PEPs a thurough read through and reformat
the rewrite using ReST; I knew I was going to have to do this anyway at
some point.

        - Alice


_______________________________________________
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: PEP 444 != WSGI 2.0

Alice Bevan–McGregor
In reply to this post by Guido van Rossum
On 2011-01-02 11:14:00 -0800, Chris McDonough said:
>> I'd suggest we just embrace it, adding minor tweaks as necessary, until
>> we reach some sort of technical impasse it doesn't address.

Async is one area that 3333 does not cover, and that by not having a
standard which incorporates async means competing, incompatible
solutions have been created.

On 2011-01-02 12:00:39 -0800, Guido van Rossum said:
> Actually that does sound like an opinion on the technical merits. I
> can't tell though, because I'm not familiar enough with PEP 444 to know
> what the critical differences are compared to PEP 3333. Could someone
> summarize?

Async, distinction between byte strings (type returned by socket.read),
native strings, and unicode strings, thorough unicode decoding (moving
some of the work from middleware to the server), simplified call syntax
(no more start_response), and clear, consice language with easy
references via numbered lists.

The async part is an idea in my head that I really do need to write
down, clarified with help from agronholm on IRC.  The futures PEP is
available as a pypi installable module, is core in 3.2, and seems to
provide a simple enough abstract (duck-typed) interface that it should
be usable as a basis for async in PEP 444.

There are parts I need to add back, of course.  file_wrapper, examples,
rationale, and references being a few of the items not yet rewritten.

        - Alice.


_______________________________________________
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: PEP 444 != WSGI 2.0

Guido van Rossum
In reply to this post by Alice Bevan–McGregor
On Sun, Jan 2, 2011 at 12:14 PM, Alice Bevan–McGregor <[hidden email]> wrote:
On 2011-01-02 09:21:29 -0800, Guido van Rossum said:
Alice hasn't posted a link to her rewrite of PEP 444 in a while. AFAICT it's this: https://github.com/GothAlice/wsgi2/blob/master/pep444.textile . I find it a bit disturbing that the "official" copy of PEP 444 (http://www.python.org/dev/peps/pep-0444/ ) hasn't been updated. This is confusing for occasional observers (like myself), since the python.org copy looks quite dead. It also is not in line with the PEP workflow as written down in PEP 1 (http://www.python.org/dev/peps/pep-0001/#pep-work-flow ).

I am unsure of the policy behind updating a PEP on the website from a partial (with glaring holes) source.  In my rewrite there are several sections that need to be fleshed out before I would consider pushing it up-stream.

I'm tentative that way.  ;)

Please drop the perfectionism. It is unpythonic. :) We believe in "release early, release often" here.

Even if *you* believe there are no glaring holes, others will find them anyway. The point of having incomplete drafts up on the website (and in SVN) is that everybody has the same chance of seeing the draft. (Also note that the website version is the first hit if you type "PEP 444" into a search engine.) If it's incomplete in places, just put XXX markers in it. People are used to this. Publication to the website does not imply any kind of approval -- it just is a mechanism for people to comment on a draft in a uniform way. (Also, a detailed SVN history might help people see the relevant changes -- a big bulk update doesn't shed much light on what changed since it looks like *everything* changed.)
 
PEP 3333 is an excellent solution that should be quick to adopt.  My PEP 444 rewrite takes a fundamentally different approach in an attempt to simplify and solve broader problems than pure compatibility.

It might be good if you summarized the differences, either here (on the list) or in the PEP itself. Unlike the documents issued by some standards bodies, Python PEPs are meant to be readable documents, and can contain sections about motivation, history, examples, whatever else the author deems likely to sway its acceptance. The formal specification itself can be in a section labeled as such.  (PS: I saw you just posted a quick summary, for which I am grateful. Maybe you can add a more thorough one to the PEP itself.)

First, it would be great if Alice could prepare a version of her draft in the format required for PEPs, and submit it to the PEP editors.

I will make this a priority.

Great!

--
--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: PEP 444 != WSGI 2.0

Masklinn
In reply to this post by Alice Bevan–McGregor
On 2011-01-02, at 21:38 , Alice Bevan–McGregor wrote:
> On 2011-01-02 11:14:00 -0800, Chris McDonough said:
>>> I'd suggest we just embrace it, adding minor tweaks as necessary, until we reach some sort of technical impasse it doesn't address.
> Async is one area that 3333 does not cover, and that by not having a standard which incorporates async means competing, incompatible solutions have been created.
>
If I remember the previous Web3 discussion correctly, the result was basically that async has no business being shoehorned in WSGI, that WSGI's model is fundamentally unfit for async and you can't correctly support sync and async with the same spec, and therefore an asynchronous equivalent to WSGI should be developed separately, in order to correctly match the needs of asynchronous servers and interfaces, without the cruft and inadequacies of being forked from a synchronous gateway model.
_______________________________________________
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: PEP 444 != WSGI 2.0

Guido van Rossum
In reply to this post by Alice Bevan–McGregor
It sounds like async could be a separate PEP, if that will make acceptance of PEP 444 easier.

On Sun, Jan 2, 2011 at 12:38 PM, Alice Bevan–McGregor <[hidden email]> wrote:
On 2011-01-02 11:14:00 -0800, Chris McDonough said:
I'd suggest we just embrace it, adding minor tweaks as necessary, until we reach some sort of technical impasse it doesn't address.

Async is one area that 3333 does not cover, and that by not having a standard which incorporates async means competing, incompatible solutions have been created.


On 2011-01-02 12:00:39 -0800, Guido van Rossum said:
Actually that does sound like an opinion on the technical merits. I can't tell though, because I'm not familiar enough with PEP 444 to know what the critical differences are compared to PEP 3333. Could someone summarize?

Async, distinction between byte strings (type returned by socket.read), native strings, and unicode strings, thorough unicode decoding (moving some of the work from middleware to the server), simplified call syntax (no more start_response), and clear, consice language with easy references via numbered lists.

The async part is an idea in my head that I really do need to write down, clarified with help from agronholm on IRC.  The futures PEP is available as a pypi installable module, is core in 3.2, and seems to provide a simple enough abstract (duck-typed) interface that it should be usable as a basis for async in PEP 444.

There are parts I need to add back, of course.  file_wrapper, examples, rationale, and references being a few of the items not yet rewritten.


       - Alice.


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



--
--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: PEP 444 != WSGI 2.0

Guido van Rossum
In reply to this post by Masklinn
On Sun, Jan 2, 2011 at 12:55 PM, Masklinn <[hidden email]> wrote:
On 2011-01-02, at 21:38 , Alice Bevan–McGregor wrote:
> On 2011-01-02 11:14:00 -0800, Chris McDonough said:
>>> I'd suggest we just embrace it, adding minor tweaks as necessary, until we reach some sort of technical impasse it doesn't address.
> Async is one area that 3333 does not cover, and that by not having a standard which incorporates async means competing, incompatible solutions have been created.
>
If I remember the previous Web3 discussion correctly, the result was basically that async has no business being shoehorned in WSGI, that WSGI's model is fundamentally unfit for async and you can't correctly support sync and async with the same spec, and therefore an asynchronous equivalent to WSGI should be developed separately, in order to correctly match the needs of asynchronous servers and interfaces, without the cruft and inadequacies of being forked from a synchronous gateway model.

Masklinn, those are pretty strong words (bordering on offensive). I'm sure Alice has a different opinion. Alice, hopefully you can write down your ideas for all to see? Perhaps you have an implementation too? Maybe seeing a concrete proposal will help us all see how big or small of a shoehorn will be needed.

(Just trying to keep this thread from degenerating into a shouting match.)

--
--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: PEP 444 != WSGI 2.0

Alice Bevan–McGregor
On 2011-01-02 13:31:45 -0800, Guido van Rossum said:
> Masklinn, those are pretty strong words (bordering on offensive). I'm
> sure Alice has a different opinion. Alice, hopefully you can write down
> your ideas for all to see? Perhaps you have an implementation too?
> Maybe seeing a concrete proposal will help us all see how big or small
> of a shoehorn will be needed.

I will be experimenting with a futures-based async implementation in
marrow.server.http while writing, as I have been with the draft rewrite
so far.

> (Just trying to keep this thread from degenerating into a shouting match.)

I missed how his statements could be construed as offensive.  :/  I
interpreted the multiple "you can't" references to be careless
shorthand, not explicitly me, so no harm done.

On 2011-01-02 12:55:30 -0800, Masklinn said:
>> If I remember the previous Web3 discussion correctly, the result was
>> basically that async has no business being shoehorned in WSGI, that
>> WSGI's model is fundamentally unfit for async and you can't correctly
>> support sync and async with the same spec, and therefore an
>> asynchronous equivalent to WSGI should be developed separately, in
>> order to correctly match the needs of asynchronous servers and
>> interfaces, without the cruft and inadequacies of being forked from a
>> synchronous gateway model.

That may have been the result of the previous discussions, however I
belive I can both write a specification that may be acceptable to
enough developers, and write a reference implementation illustrating
both asynchronous and synchronous requests while remaining performant.

        - Alice.


_______________________________________________
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
123