The question has come up on a code review whether we should use the
warnings module or logging to warn in code that doesn’t otherwise use a logger. AFAICT, DM’s conventions don’t provide any guidance on this, and the fact that we’re discussing it on a code reviews means they probably should.
I see the arguments as:
warningsis the built-in module Python has for this, and as such it should probably be the default in the absence of a reason not to use it. That broad community also means it’s easier to find documentation and recipes for (such as how to test that warnings are emitted), and it’s more likely weird edge cases will have been encountered and made to work well already.
If we believe it’s good practice for all code (of the kind we work with) to be well-instrumented with debug logs anyway (a reasonable argument, but not one I am passionate about either way), once you’ve got that set up in a module, it’s easy to warn via logs, and no extra integration is needed to capture these warnings in our logging system.
Most of our code that already has logs (quite a bit; it’s all
Tasks, and then some) pretty much exclusively uses logs to warn, so it’s probably the more common pattern in our codebase right now.
We also already use
warningspretty extensively, especially for deprecation.
Third party code that we call will use
warnings, and we should probably make sure those appear in our logs no matter how we capture them, if they don’t already. (The same is true of built-in Python
logging, but that’s beside the point, I think.)
It is easier to control
warningsverbosity based on the kind of warning, and easier to control log-based warning verbosity based on the location on the warning (though one can abuse either “kind of warning” or “logger name” to mean the other).
What say other pundits?