OK, go for it unless Glyph pipes up. :-)
On Fri, Feb 7, 2014 at 2:03 PM, Yury Selivanov <[email protected]>wrote: > On 2/7/2014, 4:47 PM, Guido van Rossum wrote: > >> On Fri, Feb 7, 2014 at 1:37 PM, Yury Selivanov<[email protected] >> >wrote: >> >> > >>> >On 2/7/2014, 3:52 PM, Guido van Rossum wrote: >>> > >>> >>>> >>Can't you add a reference to the loop to the tb logger object? The >>>> loop >>>> >>should outlive any futures anyway (since the future has a reference >>>> to the >>>> >>loop) and it shouldn't be a ref cycle. >>>> >> >>>> >> Sure. >>>> >>> > >>> >Another question: "logger.exception" is also used in: >>> > >>> >- selector_events.py: in _accept_connection, in case of errors in >>> >pause_writing/resume_writing and _fatal_error >>> > >>> >- proactor_events.py: in case of failed accept, _fatal_error and errors >>> in >>> >pause/resume writing >>> > >>> >- unix_events.py: In pipe transport's _fatal_error, in case of >>> exception >>> >in SIGCHLD handler >>> > >>> >- windows_events.py: pipe accept failed >>> > >>> >All of the above sites are logging exceptions (typically OSErrors). >>> Should >>> >we use the loop exception API there, or you want to keep using loggers >>> >directly? >>> > >>> >> I've got a hunch saying that every place where we log an exception we >> should use the new handler, but TBH I don't have much of a use case -- >> I've >> been very happy with the default logging and I would probably just be >> configuring the logger rather than overriding the exception handler. >> >> I think it's time to ask Glyph for a use case that can't be dealt with by >> overriding the logger. >> >> >> I'm +1 on using the loop API everywhere. It just gives us more > control and flexibility in improving/working with error reporting > later down the road. Using logger directly feels inconsistent. > > Yury > -- --Guido van Rossum (python.org/~guido)
