[Python-ideas] The async API of the future

Antoine Pitrou solipsis at pitrou.net
Sun Oct 21 02:07:40 CEST 2012

On Sun, 21 Oct 2012 12:41:41 +1300
Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Richard Oudkerk wrote:
> > I don't see why a completion api needs to create wrappers for sockets.  See
> > 
> >     http://pastebin.com/7tDmeYXz
> > 
> > ...
> > 
> > The AsyncIO class is independent of reactors, futures etc.  The methods 
> > for starting an operation are
> > 
> >     recv(key, sock, nbytes, flags=0)
> >     send(key, sock, buf, flags=0)
> >     accept(key, sock)
> >     connect(key, sock, address)
> That looks awfully like a wrapper for a socket to me. All of those
> system calls are peculiar to sockets.
> There doesn't necessarily have to be a wrapper class for each kind
> of file descriptor. There could be one I/O class that handles everything,
> or there could just be a collection of functions.
> The point is that, with a completion-based model, you need a function
> or method for every possible system call that you might want to perform
> asynchronously.

There aren't that many of them, though: the four Richard listed should
already be enough for most network applications, AFAIK.

I really think Richard's proposal is a sane building block.



More information about the Python-ideas mailing list