goatsweater
commented
4 years ago The default message format becomes more more useful when employed with a python package layout and loggers configured via logging.getLogger(__name__). As an example, messages from a command name "distrib" buried within a geobasenrn.nrn package appear as follows:
WARNING:geobasenrn.nrn.distrib:warning message
ERROR:geobasenrn.nrn.distrib:error message
CRITICAL:geobasenrn.nrn.distrib:critical messageThis helps in tracing the problem to exactly which file the message comes from. The format can be expanded to include line numbers or other relevant items of concern.
Is your feature request related to a problem? Please describe. All loggers in the scripts currently use
logging.getLogger()to create a new logger based onROOT. While this correctly configures logging for use, it makes it near impossible to know which messages are coming from what types of issues.Describe the solution you'd like Using named loggers, declared in the form of
logging.getLogger('class name')allows assigning a name to the logger that will be carried through when the logging messages are output (depending on formatting). This would make tracing much more convenient.Describe alternatives you've considered Trying to include names for messages as part of the message itself is error prone and will likely result in inconsistent implementation. Using a named class solves this by ensuring the name is declared once and referenced many times.
Additional context With the suggestion to move towards a package format, loggers could be named based on the value of
__name__. This would automatically set the loggers up to reflect the module they are being used in, making the messaging more clear and making tracing easier.It's conceivable that there are reasons to have more names than just the module names themselves, but I think breaking messages down along a hierarchy is a functional way to achieve clarity while minimizing the number of classes used. For example, module level logging could be declared using the module name found in
__name__, but maybe validation messages have more specific subclasses to represent the type of validation being performed (or maybe the modules break down that way anyway). This would givevalidation.geometryandvalidation.attributesto help differentiate the different types of messages, and combined with the logging levels already defined allows for a significant amount of flexibility.