Python LoggingIt turns out to be really far more complicated than I imagined a lot of a lot of learning routes comparable to git. but can not be bypassed, alternatives and less, so must pay attention to, down-to-earth seriously to learn properly to do so.
Learn the purpose of Logging:
Simple scripts are ok, print is enough.
But with a little more complexity, even three or four files adding up to two or three hundred lines of code, debugging starts to get complicated.
Plus if it's the kind of script that runs in the background for long periods of time, the investigation of the runtime information is even more complicated.
At first I was checking all sorts ofcrontabThe log view, or thepythonRun the view in the background, orpython stdoutaccess, etc., all looking in the wrong direction.
The real solution lies in proper logging.
With logging, I don't need to go to python's console output stdout, or crontab's logs, I can just look at the log file.
Here is the logging learning log for python.
Simplest log output (no documentation)
import logging
("An error has occurred.")
("Print information")
("Warning message")
First of all, forget the ()! Forget the ()!
Various online articles about python logging are really too inconsiderate of newbies, logging such a complex thing is trying to appear very simple, but also with a variety of simple things to make false impressions.
In fact, the logs that we're actually going to use up are definitely not going to be directly used with()cap (a poem)()Such, this is the official launch of this module to confuse people - it looks like it allows you to get started with one click and see the results quickly, but it really doesn't match the reality!
So for the sake of ease of explanation later, this must be a warning: forget them both!
Remember, the only way to uselogging.Whatever, it's just()This time.
Understanding the workflow of logging
Don't want to get on a flowchart type thing, that would be more confusing instead.
Keep it simple:
loggingThe module is the one that will automatically put your customized logger objects into the module.globalizationThe.
That is, if you define a certain logger, say called log, once in your own module, then any other file running in the same module will be able to read it.
For example, you've customized a logger in the main file, maybe set up some kind of output file, output format, whatever, and then you've set it up in theThere will be references to other files or modules in theThen you don't have to set anything up in this one, just use the phraselogger = ('The name of the logger previously defined')Get access to all previous customization settings.
Of course, the called files (called submodules for now) with the('Log name')When doing so, it is best to add a. SubnamesThis way, for example. That way the output will show that a certain log entry came from this file. Of course, . The parent logger in front of it must have the same name and is recognized!
Then, sublogging can be sub-logged again, and even a sub-module can be sub-logged again so that all functions each have yet another sub-sub-logging, like .func1 for example. logging will all be based on . The logging will recognize the hierarchical relationship.
In that case, it's actually the same sort of mechanism that class class inheritance has. You inherit by parent name, and then you can also rewrite your own new settings and so on.
It's only after you understand these concepts that you can come to the code. It's actually much better to understand.
Methods for setting up the logger
This article is the most comprehensive and clear, and many of the following references are to it: Python 101: An Intro to logging
Generally want to customize a logger, such as let it output information in what format to display, output to which file, to be output to the screen class, there are three ways to achieve the settings:
- Set it up directly in the python code
- Configuration with external files
- Configuration with python's dict dictionary
Three to achieve the same purpose, the dictionary is used by very few people is not convenient, configuration files are better just .ini syntax is not very easy to read, and it is not easy to do the dynamic setting of variables, so generally directly in the python code to write.
Common Setup Statements
The following is a generic way to write the main entry file of a program. Note that the logger must be defined in the main entry so that all other submodules can inherit it.
#
import logging
import otherMod2 # Submodules that will be called later on
def main():
"""
This file is the main entry point to the program
"""
define_logger()
log = ('exampleApp')
# Output message test
("Program started")
result = (7, 8) # This is a method from another module
("Done!")
def define_logger():
logger = ("exampleApp")
()
# Set the output format
formatter = ('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
# Set up the log file processor
fh = ("new_snake.log")
(formatter) # Add formatting to this processor
# Setting up the screen stdout output processor
sh = (stream=None)
(formatter)
# Add the processor to the logger
(fh)
(sh)
if __name__ == "__main__":
main()
Here's how it's called in the submodule (it's simple):
#
import logging
module_logger = ("exampleApp.otherMod2")
def add(x, y):
# The phrase `getLogger` here inherits from the parent logger.
logger = ("exampleApp.")
# Output testing
("added %s and %s to get %s" % (x, y, x+y))
return x+y
Note that it's fine to define the logger anywhere in the main file, either in main() or in any separate function or class, it doesn't matter. As long as it's defined before calling the submodule, it's fine. Once defined, the logger name is memorized and then the submodule can easily inherit it.
This is the whole content of this article.