[Python-ideas] The async API of the future: Twisted and Deferreds

[Antoine Pitrou]

On Sat, 13 Oct 2012 22:03:17 -0700
Guido van Rossum <guido at python.org> wrote:
> >
> > But how would you write a dataReceived equivalent then? Would you have
> > a "task" looping on a read() call, e.g.
> >
> > @task
> > def my_protocol_main_loop(conn):
> >     while <some_condition>:
> >         try:
> >             data = yield conn.read(1024)
> >         except ConnectionError:
> >             conn.close()
> >             break
> 
> No, I would use plain callbacks. There would be some kind of IOObject
> class defined by the stdlib that wraps a socket (it would make it
> non-blocking, and possibly to other things), and the user would make a
> registration call to the event loop giving it the IOOjbect and the
> user's callback function plus *args and **kwds; the event loop would
> call callback(*args, **kwds) each time the IOObject became readable.
> (Oh, and there would be separate registration (and unregistration)
> functions for reading and writing.)
> 
> Apparently my rants about callbacks have made people assume that I
> don't want to see them anywhere. In fact I am comfortable with
> callbacks for a number of situations -- I just think we have several
> other tools in our toolbox that are way underused, whereas callbacks
> are way overused, in part because the alternative tools are relatively
> new.
> 
> This way the user could switch to a different callback when a
> different phase of the protocol is reached. I realize there are other
> shapes this API could take. But I really don't want the user to have
> to subclass IOObject.

Subclassing IOObject would be wrong, since the user isn't writing an IO
object in the first place. But subclassing a separate class, like
Twisted's Protocol (which is mostly an empty shell, really), would sound
reasonable to me.

Regards

Antoine.


-- 
Software development and contracting: http://pro.pitrou.net