Oops, it was pointed out to me that this message isn't super clear. To put it more simply:
Please go ahead and do this, using the loop API everywhere would be a lot better for my uses :-). -glyph On Feb 10, 2014, at 5:12 PM, Glyph <gl...@twistedmatrix.com> wrote: > I have a use-case, which is to direct Twisted's logging to Tulip's (or vice > versa) in a way which behaves consistently. Using the logger directly is, as > I said in a message a long time ago, a really wide interface for alternate > logging systems to try to use. > > (And stdlib logging.py is slow enough that it can seriously start to impact > your frame rate if you're trying to do logging from a GUI, so there's still a > pretty substantial use-case for Twisted's logging client-side. This is > probably less true than it was 10 years ago when I really cared deeply about > this for my day job, but nevertheless, I still dream of making some cool > games in Python ;-).) > > On Feb 7, 2014, at 4:18 PM, Guido van Rossum <gu...@python.org> wrote: > >> OK, go for it unless Glyph pipes up. :-) >> >> >> On Fri, Feb 7, 2014 at 2:03 PM, Yury Selivanov <yselivanov...@gmail.com> >> wrote: >> On 2/7/2014, 4:47 PM, Guido van Rossum wrote: >> On Fri, Feb 7, 2014 at 1:37 PM, Yury Selivanov<yselivanov...@gmail.com>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) >
