[issue29415] Exposing handle._callback and handle._args in asyncio

2017-02-01 Thread Yury Selivanov
Yury Selivanov added the comment: > @yselivanov I just wanted to use the handler to avoid storing the callback > and args in my own data structure (I would just store the handlers whenever I > may need to reschedule). Not a big deal, I don't have to use handler as a > storage space, if it's no

[issue29415] Exposing handle._callback and handle._args in asyncio

2017-02-01 Thread Max
Max added the comment: @yselivanov I just wanted to use the handler to avoid storing the callback and args in my own data structure (I would just store the handlers whenever I may need to reschedule). Not a big deal, I don't have to use handler as a storage space, if it's not supported across

[issue29415] Exposing handle._callback and handle._args in asyncio

2017-02-01 Thread Yury Selivanov
Yury Selivanov added the comment: > Is it safe to use the _callback and _args attributes of asyncio.Handle? Is it > possible to officially expose them as public API? I'd be -1 on exposing them. Alternative asyncio event loop implementations such as uvloop don't have those attributes, and it's

[issue29415] Exposing handle._callback and handle._args in asyncio

2017-02-01 Thread Max
New submission from Max: Is it safe to use the _callback and _args attributes of asyncio.Handle? Is it possible to officially expose them as public API? My use case: handle = event_loop.call_later(delay, callback) # this function can be triggered by some events def reschedule(han