[Python-ideas] async: feedback on EventLoop API

[Guido van Rossum]

On Mon, Dec 17, 2012 at 12:56 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 17 Dec 2012 12:49:46 -0800
> Guido van Rossum <guido at python.org> wrote:
>> On Mon, Dec 17, 2012 at 11:57 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> > On Mon, 17 Dec 2012 09:47:22 -0800
>> > Guido van Rossum <guido at python.org> wrote:
>> >>
>> >> (BTW, can someone *please* come up with a better name for DelayedCall?
>> >> It's tedious and doesn't abbreviate well. But I don't want to name the
>> >> class 'Callback' since I already use 'callback' for function objects
>> >> that are used as callbacks.)
>> >
>> > Does it need to be abbreviated? I don't think users have to spell
>> > "DelayedCall" at all (they just call call_later()).
>>
>> They save the result in a variable. Naming that variable delayed_call
>> feels awkward. In my code I've called it 'dcall' but that's not great
>> either.
>>
>> > That said, some proposals:
>> > - Timer (might be mixed up with threading.Timer)
>>
>> But often there's no time involved...
>
> Ah, I see you use the same class for add_reader() and friends. I was
> assuming that, like in Twisted, DelayedCall was only returned by
> call_later().
>
> Is it useful to return a DelayedCall in add_reader()? Is it so that you
> can remove the reader? But you already define remove_reader() for that,
> so I'm not sure what an alternative way to do it brings :-)

I'm not sure myself. I added it to the PEP (with a question mark)
because I use DelayedCalls to represent I/O callbacks internally --
it's handy to have an object that represents a function plus its
arguments, and I also have a shortcut for adding such objects to the
ready queue (the ready queue *also* stores DelayedCalls).

It is probably a mistake offering two ways to cancel an I/O callback;
but I'm not sure whether to drop remove_{reader,writer} or whether to
drop cancelling the callback. (The latter would means that
add_{reader,writer} should not return anything.) I *think* I'll keep
remove_* and drop callback cacellation, because the entity that most
likely wants to revoke the callback already has the file descriptor in
hand (it comes with the socket, which they need anyway so they can
call its recv/send method), but they would have to hold on to the
callback object separately. OTOH callback objects might make it
possible to have multiple callbacks per FD, which I currently don't
support. (See discussion earlier in this thread.)

-- 
--Guido van Rossum (python.org/~guido)