On Wed, Feb 26, 2020 at 3:58 AM Rémi Lapeyre <remi.lapeyre@henki.fr> wrote:
> Why does this deserve in the stdlib?
> (The stdlib does very little logging of its own -- logging is up to the application.)

Some parts of the stdlib output some logs like urllib, I think only the configuration of the handlers is up to the application.

I don't see any logging calls in urllib. If you know of any, can you point me to them? (There are some warnings.warn() calls, but that's different.)
 
Is the stdlib not generating logs because of the overhead of calling logging.info()?

Perhaps in part, because I think mostly logging is considered the application's responsibility. There's also the issue of how to direct logging -- does every module have its own logger object, or every class, or does every *instance* of a class that may do something loggable have its own logger? Either way, the logging becomes a new, explicit part of the API to which the application (or the library calling it) should have access. And yes, such APIs would have a lot of overhead.

I suspect that the libraries you referred to that wrap calls you wanted to be logged have the same attitude: logging is up to the application.

I have worked extensively with large code bases that did a considerate amount of logging, and I've never felt the need (not heard others express it) to have logging in the stdlib.
 
> It's not logging per se, but the standard library does have an
> extensive and growing list of audit events that are intended to assist
> with testing, logging and security monitoring.

Thanks, It looks like an audit hook could work.

But understand that these are meant for a totally different purpose.

--
--Guido van Rossum (python.org/~guido)