In a nutshell: Let's stop
Please read the following as a story.
log4j (http://ja.wikipedia.org/wiki/Log4j) has a level called TRACE under DEBUG. I think this is an ant function.
For example, at the beginning and end of a function, "started!" And "finished!"
If you write in TRACE log level, or `` LOG.trace () `, etc., and write the middle process in DEBUG
It's like being able to define multiple stages like -vv (in the case of ssh) for -v at a slightly more meaningful level.
When a bug comes, grass is inevitable.
During development, there are cases where it would be nice to know at the log level "which function worked to the end". It's not always possible to run the debugger in the whole story, and somehow I use "printf debug". help.
Python log levels are numbers in the first place, and DEBUG, INFO, etc. are actually mapped to numbers.
https://docs.python.org/3.4/library/logging.html#logging-levels
For example, when spitting a log, write as follows
logging.debug ('shouldn't be written this way') logging.log (logging.DEBUG,'So!')
(Actually, you can use Logger)
Since logging.DEBUG is simply 10, the above notation effectively represents the output at the same log level as the following notation.
logging.log (10,'Nmo!')
NOTSET (0) is a bit special, so let's put it aside, and even if you use numbers from 1 to 9, the log function won't complain. On the contrary, DEBUG and INFO are simply treated as aliases to numbers.
`logging.log (lvl, msg)` lvl is a number and does not accept'DEBUG' etc. )So, if you specify a number such as 5 and write `logging.log (5,'wafu')` `, etc., you can write` `setLevel (logging.DEBUG)` Logger. Will not be displayed.
If you do something like TRACE by specifying numerical values, it will look like the following.
from logging import getLogger, StreamHandler, DEBUG
logger = getLogger(__name__)
handler = StreamHandler()
logger.setLevel(DEBUG)
handler.setLevel(DEBUG)
logger.addHandler(handler)
logger.log (5,'I'll start') .. logger.debug ('This is big') .. logger.log (5,'It's over')
In the above example, "Start" and "End" are not displayed. It's just "This is big". As a way to put debug logs that are really only valuable to developers Personally, I don't think it's terrible. Or rather convenient.
Here, logging has a feature called ```addLevelName ()` ``. (https://docs.python.org/3.4/library/logging.html#logging.addLevelName)
Oh, this is `logger.trace ()`
Not made :-)
logging.trace()And logger.trace()Is not made, let alone logging.log('TRACE', 'Hello')I can't do it. Logging in the first place.log('INFO', 'Let's paste')Not even allowed.
# You can specify something like ``` logger.setLevel ('INFO')` `` (to be exact, it seems to be only the latest version after 3.2. For some reason, it also includes 2.7). It is also possible to specify ``` --log = DEBUG``` with argparse and directly insert it into `` `setLevel ()` `.
Probably, this is just a function that `` `Formatter``` displays" TRACE "instead of" Level 5 ", isn't it?
(like ipython)
> import logging
> logger = logging.getLogger('test')
> logger.setLevel(1)
> handler = logging.StreamHandler()
> handler.setLevel(1)
> formatter = logging.Formatter('%(asctime)s - %(levelname)s - %(message)s')
> handler.setFormatter(formatter)
> logger.addHandler(handler)
> logger.debug('hello')
2014-05-01 11:02:12,743 - DEBUG - hello
> logger.log(5, 'hoge')
2014-05-01 11:02:20,599 - Level 5 - hoge
> logging.addLevelName(5, 'TRACE')
> logger.log(5, 'hoge')
2014-05-01 11:02:43,173 - TRACE - hoge
To be precise, if you mess with the contents of Murikuri logging, you may be able to add `` `logging.trace ()` `` etc. It's Python.
However, it doesn't exist as a nice and safe implementation by default, and I don't think it's going in that direction in the future.
Even if I could do it, I can see that it's just super troublesome.
It can't be said that the logger received by each function or the like always has it. Especially if it is provided as a library, it is visible that loggers who do not know trace come from the outside.
Sometimes I have a trace or I don't have it, so I wonder if I use it while checking with getattr.
Convenience is not fine.
# In the first place, the official says something like "don't do it".
https://docs.python.org/2/howto/logging.html#custom-levels
> Defining your own levels is possible, but should not be necessary, as the existing levels have been chosen on the basis of practical experience. However, if you are convinced that you need custom levels, great care should be exercised when doing this, and it is possibly a very bad idea to define custom levels if you are developing a library. That’s because if multiple library authors all define their own custom levels, there is a chance that the logging output from such multiple libraries used together will be difficult for the using developer to control and/or interpret, because a given numeric value might mean different things for different libraries.
https://docs.python.org/3.2/howto/logging.html#custom-levels
> Defining your own levels is possible, but should not be necessary, as the existing levels have been chosen on the basis of practical experience. However, if you are convinced that you need custom levels, great care should be exercised when doing this, and it is possibly a very bad idea to define custom levels if you are developing a library. That’s because if multiple library authors all define their own custom levels, there is a chance that the logging output from such multiple libraries used together will be difficult for the using developer to control and/or interpret, because a given numeric value might mean different things for different libraries.
https://docs.python.org/3.4/howto/logging.html#custom-levels
> Defining your own levels is possible, but should not be necessary, as the existing levels have been chosen on the basis of practical experience. However, if you are convinced that you need custom levels, great care should be exercised when doing this, and it is possibly a very bad idea to define custom levels if you are developing a library. That’s because if multiple library authors all define their own custom levels, there is a chance that the logging output from such multiple libraries used together will be difficult for the using developer to control and/or interpret, because a given numeric value might mean different things for different libraries.
# Conclusion
Let's stop
As a "debug" log for bugs that developers just don't understand, prepare one specific handler that spits out a super verbose log, set only that handler to log level 1, and the others are muddy with DEBUG. Is it enough to deal with such multi-steps?
At the very end of my insistence on "let's stop", I was convinced that "Oh, then I can't forgive", and that's it.
Recommended Posts