[Web-SIG] PEP 444 / WSGI 2 Async

[Alice Bevan–McGregor]

On 2011-01-06 09:20:48 -0800, Randy Syring said:
> Being a web application developer and relying on frameworks like 
> Werkzeug and WebOb, I may not have much of a dog in this fight.

All input is welcome; I do want to hear from both framework developers 
and users of frameworks.  I suspect this discussion ocurring on the 
Web-SIG list would be somewhat of an impediment for users to 
contribute, so thank you for posting!

> However, I have been following web-sig for a couple years and I have 
> seen the difficulties involved in reaching consensus on 
> modifying/updating the WSGI spec.

I've read through the archives and seen the issues as well.  I do 
believe that, on this one topic, it will be simply impossible to please 
everyone.  Up here in Canada we have

> Its clear to me that most people on this list who can contribute in 
> meaningful ways to the creation of WSGI 2 have very little time to do 
> so.

One benefit of mailing lists over other communications channels (IRC, 
etc.) is that mailing list traffic sticks around for a while and 
doesn't require realtime effort.

> Motivation seems generally low anyway, because what we have currently works.

The burst of traffic after Guido offered to push PEP 3333 ratification 
proves that what we have /doesn't/ currently work, at least, for 
everyone.  Python 3 continues to be a problem.

> It may have warts, but it works, and that very fact seems to limit the 
> number of people interested in donating time to improving the spec.

Limiting the scope to Python 2; PEP 333 has a number of issues 
including, I feel the worst sins for a "standard": ambiguity and 
complexity.  While people may feel comfortable with the standard they 
have learned thus far, I don't think they should be complacent when it 
comes to examining possible improvements.

> Every time something controversial is added to the spec, its going to 
> make it that much harder to move forward.

Thus my pushing for the controversial parts to be optional.  While, 
demonstrably, not everyone will use these parts, having them be present 
is important to capture mind-space and get people thinking about the 
broader implications of what they code.

> On 2011-01-06 05:03:15 -0800, Chris Dent said:
>> I agree with some others who have suggested that maybe async should be 
>> its own thing, rather than integrated into a WSGI2. A server could 
>> choose to be WSGI2 compliant or AWSGI compliant, or both.
> 
> Adding async to the spec is a death blow IMO.  You gain nothing by 
> putting it in and lose a lot of interest and time spent discussing it.  
> Make it a separate PEP that references the first.  That way, those who 
> don't really care about it can still work on WSGI 2 without the 
> distraction of the async parts.  If you make the new async PEP 
> dependent on the WSGI 2 spec, then those ideas can be tossed around all 
> day long without distracting from or taking energy away from the core 
> WSGI 2 ideas.

Tossing the idea around all day long will then, of course, be happening 
regardless.  Unfortunately for that particular discussion, PEP 3148 / 
Futures seems to have won out in the broader scope.  Having a ratified 
and incorporated language PEP (core in 3.2 w/ compatibility package for 
2.5 or 2.6+ support) reduces the scope of async discussion down to: 
"how do we integrate futures into WSGI 2" instead of "how do we define 
an async API at all".

> I suggest reviewing the Web-SIG history of previous async discussions; 
> there's a lot more to having a meaningful API spec than having a 
> plausible approach.  It's not that there haven't been past proposals, 
> they just couldn't get as far as making it possible to write a 
> non-trivial async application that would actually be portable among 
> Python-supporting asynchronous web servers.

See my previous paragraph about futures.

> [snip]
> 
> We only see what you write here, the burden of proof is on you to 
> communicate your attentions and agenda.

Unfortunately the reality is that no solution will be agreeable to 
everyone, and, for lack of a better phrase, no amount of hand-holding 
can make it otherwise.

I am attempting to improve my PR somewhat through the many posts today 
and with as much thorough information as possible.  ;)

> Then again, my opinion and impression could be completely off, and if 
> that is the case, feel free to ignore me.  :)

That, despite popular opinion otherwise, is something I rarely do, 
though my brain is so full these days that some things might get 
accidentally expunged from my LRU heap.  ;)

	- Alice.