On Sat, 13 Oct 2012 22:03:17 -0700 Guido van Rossum <guido@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