On Mon, Oct 29, 2012 at 8:10 PM, Guido van Rossum <guido@python.org> wrote:
On Mon, Oct 29, 2012 at 11:02 AM, Andrew Svetlov <andrew.svetlov@gmail.com> wrote:
Pollster has to support any object as file descriptor. The use case is ZeroMQ sockets: they are implemented at user level and socket is just some opaque structure wrapped by Python object. ZeroMQ has own poll function to process zmq sockets as well as regular sockets/pipes/files.
Good call! This seem to be an excellent use case to validate the pollster design. Are you saying that the approach I used for SslTransport doesn't work here? (I can believe it, I've never looked at 0MQ, but I can't tell from your message.) The insistence on isinstance(fd, int) is mostly there so that I don't accidentally register a socket object *and* its file descriptor at the same time -- but there are other ways to ensure that. I've added a TODO item for now.
0MQ socket has no file descriptor at all, it's just pointer to some unspecified structure. So 0MQ has own *poll* function which can process that sockets as well as file descriptors. Interface is mimic to poll object from python stdlib. You can see https://github.com/zeromq/pyzmq/blob/master/zmq/eventloop/ioloop.py as example. For 0MQ support tulip has to have yet another reactor implementation in line of select, epoll, kqueue etc. Not big deal, but it would be nice if PollsterBase will not assume the registered object is always int file descriptor.
I would to see add_{reader,writer} and call_{soon,later} accepting **kwargs as well as *args. At least to respect functions with keyword-only arguments.
Hmm... I intentionally ruled those out because I wanted to leave the door open for keyword args that modify the registration function (add_reader etc.); it is awkward to require conventions like "your function cannot have a keyword arg named X because we use that for our own API" and it is even more awkward to have to retrofit new values of X into that rule. Maybe we can come up with a simple wrapper.
It can be solved easy with using names like __when, __callback etc. That names will never clutter with user provided kwargs I believe.
+1 for explicit passing loop instance and clearing role of DelayedCall.
Will do. (I think you meant clarifying?)
Exactly. Thanks.
Decorating coroutines with setting some flag looks good to me, but I expect some problems with setting extra attribute to objects like staticmethod/classmethod.
Noted.
-- --Guido van Rossum (python.org/~guido)
Thank you, Andrew Svetlov