[Python-ideas] Async API: some code to review

[Andrew Svetlov]

On Mon, Oct 29, 2012 at 8:10 PM, Guido van Rossum <guido at python.org> wrote:
> On Mon, Oct 29, 2012 at 11:02 AM, Andrew Svetlov
> <andrew.svetlov at 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