I have put many logging print() statements in when I really should have been using the logging system.
Part of it is that I am not satisfied with the ability of the python log system to filter out different kinds of events. For instance, I would probably want to see occasional progress events. If a process had five phases, the transitions should be visible. However these are level INFO. However there are many WARNING type messages that might be more frequent but still should be suppressed, In fact even some kinds of ERROR messages should be suppressed if the errors are recoverable.
I haven't found a mapping between python logging system concepts and "what I want to log" and I feel that is less acute than it was in Java partially because I was putting loggers on the class level in Java (and building classes in an idiomatic Java way) but mostly putting loggers on the module level in Python.
That is some of it, but not all of it. Some people might expect "progress reporting" to be distributed in multiple parts of the code, thus there would be some kind of "tag" associated with log messages which are of this kind.
Another way to do it is to have a module or class that is responsible for progress reporting and then add a little complexity to the rules so that that object is logged at INFO while other objects are logged at ERROR or WARN.
Related to all this is having an easy way to configure the logging level not just overall but for the whole hierarchy.
It has to be easier to use this mechanism than it is to stick in print(), otherwise I will keep sticking in print()s.
I have put many logging print() statements in when I really should have been using the logging system.
Part of it is that I am not satisfied with the ability of the python log system to filter out different kinds of events. For instance, I would probably want to see occasional progress events. If a process had five phases, the transitions should be visible. However these are level INFO. However there are many WARNING type messages that might be more frequent but still should be suppressed, In fact even some kinds of ERROR messages should be suppressed if the errors are recoverable.
I haven't found a mapping between python logging system concepts and "what I want to log" and I feel that is less acute than it was in Java partially because I was putting loggers on the class level in Java (and building classes in an idiomatic Java way) but mostly putting loggers on the module level in Python.
That is some of it, but not all of it. Some people might expect "progress reporting" to be distributed in multiple parts of the code, thus there would be some kind of "tag" associated with log messages which are of this kind.
Another way to do it is to have a module or class that is responsible for progress reporting and then add a little complexity to the rules so that that object is logged at INFO while other objects are logged at ERROR or WARN.
Related to all this is having an easy way to configure the logging level not just overall but for the whole hierarchy.
It has to be easier to use this mechanism than it is to stick in print(), otherwise I will keep sticking in print()s.