On Thu, Feb 6, 2014 at 2:54 PM, Yury Selivanov <[email protected]>wrote:
> A question to you and Guido: should the callback receive
> three arguments: loop, exception, and context, where
> context is a namedtuple (so we can add new fields to it
> in future releases). For now, 'context' can have two fields:
> 'message' and 'callback'. The former is the log message, and
> the latter is the failed callback function (or None).
>
Hm... I don't like to have this much structure, but I do know that it's a
pain to extend a callback API with new information, so I think it's a good
idea. But maybe apart from the loop everything should be passed this way
(i.e. also the exception)? And may I suggest to make it a dict instead of a
named tuple? It's easier to check a dict for the presence of something that
may or may not exist.
> Another option is to have a loop method to get the current/last
> executed callback.
>
Much less flexible.
BTW I don't like the excepthook/displayhook API much -- the sys module has
lots of objects that you are allowed to assign to, but that's a bit of a
historical accident (see e.g. the recent request to make
sys.std{in,out,err} thread-local). I would like to go ahead with the
proposed API (set_exception_handler, default_exception_handler,
call_exception_handler). I don't see much of a use case for
saving/restoring these outside unittests (where the better approach is to
just create a new event loop). The expected usage pattern is to set a
custom handler in main() right after creating the loop. A framework that
wants some kind of "pass the buck" behavior can build that on top of the
basic API combined with a convention.
--
--Guido van Rossum (python.org/~guido)
