[Web-SIG] PEP 444 / WSGI 2 Async

[Alice Bevan–McGregor]

On 2011-01-06 03:53:14 -0800, Antoine Pitrou said:
> Alice Bevan-€“McGregor <alice at ...> writes:
>> GothAlice: ... native string usage, the definition of "byte string" as 
>> "the format returned by socket read" (which, on Java, is unicode!) ...

Just so no-one feels the need to correct me; agronholm made sure I 
didn't drink the kool-aid of one article I was reading and basing some 
ideas on.  Java socket ojects us byte-based buffers, not unicode.  My 
bad!

> Regardless of the rest, I think the latter would be a large step backwards.
> Clear distinction between bytes and unicode is a *feature* of Python 3.
> Unicode-ignorant programmers should use frameworks which do the encoding work
> for them.

+0.5

I'm beginning to agree; with the advent of b'' syntax in 2.6, the only 
compelling reason to include this "feature" (examples that work without 
modification across major versions of Python) goes up in smoke.  The 
examples should use the b'' syntax and have done with it.

> (by the way, why you are targeting both Python 2 and 3?)

For the same reason that Python 3 features are introduced to 2.x; 
migration.  Users are more likely to adopt something that doesn't 
require them to change production environments, and 3.x is far away 
from being deployed in production anywhere but on Gentoo, it seems.  ;)

Broad development and deployment options are a Good Thing™, and with 
b'', there is no reason -not- to target 2.6+.  (There is no requirement 
that a PEP 444 / WSGI 2 server even try to be a cross-compatible 
polygot; there is room for 2.x-specific and 3.x-specific solutions, 
and, in theory, it should be possible to support Python < 2.6, I just 
don't feel it's worthwhile to lock your application into Very Old™ 
interpreters.)

>> agronholm: I'm not very comfortable with the idea of wsgi.input in
>> async apps \ I'm just thinking what would happen when you do
>> environ['wsgi.input'].read()
>> 
>> GothAlice: One of two things: in a sync environment, it blocks until it
>> can read, in an async environment [combined with yield] it
>> pauses/shelves your application until the data is available.
> 
> Er, for the record, in Python 3 non-blocking file objects return None when
> read() would block.

-1

I'm aware, however that's not practically useful.  How would you detect 
from within the WSGI 2 application that the file object has become 
readable?  Implement your own async reactor / select / epoll loop?  
That's crazy talk!  ;)

>> agronholm: the requirements of async apps are a big problem
>> 
>> agronholm: returning magic values from the app sounds like a bad idea
>> 
>> agronholm: the best solution I can come up with is to have
>> wsgi.async_input or something, which returns an async token for any
>> given read operation
> 
> The idiomatic abstraction for non-blockingness under POSIX is file descriptors.
> So, at the low level (the WSGI level), exchanging fds between server and app
> could be enough to allow both to wake up each other (perhaps two fds: one the
> server can wait on, one the app can wait on). Similarly to what 
> signalfd() does.
> Then higher-level tools can wrap inside Futures or whatever else.

-0

Hmm; I'll have to mull that over.  Initial thoughts: having a magic 
yield value that combines a fd and operation (read/write) is too 
magical.

> However, this also means Windows compatibility becomes more complicated, unless
> the fds are sockets.

+1 for pure futures which (in theory) eliminate the need for dedicated 
async versions of absolutely everything at the possible cost of 
slightly higher overhead.

	- Alice.