[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.
Regards
Antoine.
More information about the Python-ideas
mailing list