[Web-SIG] PEP 444 / WSGI 2 Async

[Alice Bevan–McGregor]

On 2011-01-07 13:21:36 -0800, Antoine Pitrou said:
> Ok, so, WSGI doesn't "already involve generators". QED.

Let me try this again.  With the understanding that:

:: PEP 333[3] and 444 define a response body as an iterable.
:: Thus WSGI involves iterables through definition.
:: A generator is a type of iterable.
:: Thus WSGI involves generators through the use of iterables.

The hypothetical redefinition of an application as a generator is not 
too far out to lunch, considering that WSGI _already involves 
generators_.  (And that the simple case, an application that does not 
utilize async, will require a single word be changed: s/return/yield)

Is that clearer?  The idea refered to below (and posted separately) 
involve this redefinition, which I understand fully will have a number 
of strong opponents.  Considering PEP 444 is a new spec (already 
breaking direct compatibility via the /already/ redefined return value) 
I hope people do not reject this out of hand but instead help explore 
the idea further.

On 2011-01-07 19:36:52 -0800, Antoine Pitrou said:
> Alice Bevan–McGregor <alice at ...> writes:
>> The particular use case happens to be PEP 444 as implemented using an 
>> async and multi-process (some day multi-threaded) HTTP server, so I'm 
>> not quite sure what you're getting at, here.
> 
> It's becoming to difficult to parse. You aren't sure yet what the async 
> part of PEP 444 should look like but you have already implemented it?

Marrow HTTPd (marrow.server.http) [1] is, internally, an asynchronous 
server.  It does not currently expose the reactor to the WSGI 
application via any interface whatsoever.  I am, however, working on 
some p-code examples (that I will post for discussion as mentioned 
above) which I can base a fork of m.s.http off of to experiment.

This means that, yes, I'm not sure how async will work in PEP 444 /in 
the end/, but I am at least attempting to explore the practical 
implications of the ideas thus far in a real codebase.  I'm "getting it 
done", even if it has to change or be scrapped.

>> I helped proof a book about Python 3 compatibility and am giving a 
>> presentation in March that contains information on Python 3 
>> compatibility from the viewpoint of implementing the Marrow suite.
> 
> Well, I hope not too many people will waste time trying to write code 
> cross-compatible code rather than solely target Python 3. The whole 
> point of Python 3 is to make developers' life better, not worse.

I agree, with one correction to your first point.  Application and 
framework developers should whole-heartedly embrase Python 3 and make 
full use of its many features, simplifications and clarifications.  
However, it is demonstrably not Insanely Difficult™ to have compatible 
server and middleware implementations with the draft's definition of 
native string.  If server and middleware developers are willing to 
create polygot code, I'm not going to stop them.

Note that this type of compatibility is not mandated, and the use of 
native strings (with one well defined byte string exception) means that 
pure Python 3 programmers can be blissfully ignorant of the 
compatibility implications -- everything else is "unicode" (str), even 
if it's just "bytes-in-unicode" (latin1/iso-8859-1).  Pure Python 2 
programmers have only a small difference (for them) of the URI values 
being unicode; the remaining values are byte strings (str).

I would like to hear a technical reason why this (native strings) is a 
bad idea instead of vague "this will make things harder" -- it won't, 
at least, not measurably, and I have the proof as a working, 100% unit 
tested, performant, cross-compatible polygot HTTP/1.1-compliant server. 
 Written in several days worth of "full-time work" spread across weeks 
because this is a spare-time project; i.e. not a lot of literal work, 
nor "hard".

Hell, it has transformed from a crappy hack to experiment with HTTP 
into a complete (or very nearly so) implementation of PEP 444 in both 
of its current forms (published and draft) that is almost usable, 
ignoring the fact that PEP 444 is mutable, of course.

	- Alice.

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