4 ms·

So as a library author, how do I effectively use logging? Should I? What Is there a way to embed logging in my library, turn it off by default, and allow end-us

So as a library author, how do I effectively use logging? Should I? What Is there a way to embed logging in my library, turn it off by default, and allow end-users to turn it back on, when required?

kstrauser 15y ago
Actually, you don't configure it at all in your library. Just import logging, then call logging.{debug,info,whatever} as needed. The idiom is to do all configuration in the app which uses your libraries, such as looking for "-d" or "-dd" in sys.argv to set the logging level.
- jdunck 15y ago
  No, please don't call "logging.whatever" as needed. That uses the root logger, and that removes the consumer's ability to tune different loggers. logger = logging.getLogger("libname.foo") logger.<whatever> is much more useful and polite. Using the top-level logger is like putting this in your library: __builtins__.__dict__.update(globals()) Bad form.
jdunck 15y ago
You should, definitely. If you have subsystems where different abstractions or granularities might be useful, declare a logger for each of those. Document them clearly. Make the top-level the name of your library. "libname.foo", "libname.bar", "libname.baz" are fine. Just use only one top-level namespace. Use the logging levels appropriately. (Some libraries log everything as "warning", that's almost as bad as no logging.) "Turn it off by default" - unless you are making a lib where performance is critical, logging overhead is noise. Your containing process will set up handlers as appropriate - they can turn off your output if they know what your loggers are. For bonus points, provide logging configurations for "silent", "normal", and "debug". I agree that the logging stdlib is a bit heavy for many uses. If your goal is to "just print a string", it can be a maddening array. OK: def log(msg, kwargs): import sys print >> sys.stderr, msg % kwargs But the logging module, used properly, is much more useful than that. I wish it had better docs and a better API, but it does have some nice features.
deleted 15y ago
[deleted]

So as a library author, how do I effectively use logging? Should I? What Is there a way to embed logging in my library, turn it off by default, and allow end-users to turn it back on, when required?

kstrauser 15y ago

Actually, you don't configure it at all in your library. Just import logging, then call logging.{debug,info,whatever} as needed. The idiom is to do all configuration in the app which uses your libraries, such as looking for "-d" or "-dd" in sys.argv to set the logging level.

jdunck 15y ago
No, please don't call "logging.whatever" as needed. That uses the root logger, and that removes the consumer's ability to tune different loggers. logger = logging.getLogger("libname.foo") logger.<whatever> is much more useful and polite. Using the top-level logger is like putting this in your library: __builtins__.__dict__.update(globals()) Bad form.

jdunck 15y ago

You should, definitely. If you have subsystems where different abstractions or granularities might be useful, declare a logger for each of those. Document them clearly. Make the top-level the name of your library. "libname.foo", "libname.bar", "libname.baz" are fine. Just use only one top-level namespace. Use the logging levels appropriately. (Some libraries log everything as "warning", that's almost as bad as no logging.) "Turn it off by default" - unless you are making a lib where performance is critical, logging overhead is noise. Your containing process will set up handlers as appropriate - they can turn off your output if they know what your loggers are. For bonus points, provide logging configurations for "silent", "normal", and "debug". I agree that the logging stdlib is a bit heavy for many uses. If your goal is to "just print a string", it can be a maddening array. OK: def log(msg, kwargs): import sys print >> sys.stderr, msg % kwargs But the logging module, used properly, is much more useful than that. I wish it had better docs and a better API, but it does have some nice features.

deleted 15y ago

[deleted]