I think part of the reason that logging appears complicated is because logging actually is complicated. In the myriad different contexts a Python program runs (daemon, command line tool, interactively), the logging output should be going to all sorts of different places. Thus was born handlers. If you want "all the logs", do you really want all the logs from some library and the library it calls? Thus was born filters.
For better or worse, the "line cost" of a logging call encourages them to be useful. That said, I'd maybe like a plugin for my editor that could hide all logging statements for some "mature" projects so I could try to see the control flow a bit better. On Thu, Jan 25, 2018 at 3:03 PM, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Steve Barnes wrote: > >> I would suggest, however, that if this feature is introduced it be >> controlled via a run-time switch &/or environment variable which defaults >> to off. >> > > I disagreew with defaulting it to off. That would encourage > lazy developers to distribute library code full of #l lines, > so that when you turn it on to debug something of your own, > you get swamped with someone else's debugging messages. > > -- > Greg > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
