On Thu, Feb 6, 2014 at 2:54 PM, Yury Selivanov <yselivanov...@gmail.com>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)