You know when you set the root logger in Python to DEBUG, and annoyingly it prints debug messages from whatever libraries you're using (Pytorch, Numpy, Matplotlib, whatever)? And then you have to manually turn them off in-code, only for more debug logs from other libraries that you install later to appear?
What I want is a switch that turns all of my loggers (that I got from logging.getLogger(__name__)) to level DEBUG, but not anything else. I initially thought about having a "root" logger for all of my code, named my_root, say, and defining my own get_logger() that wraps around logging.getLogger() by prepending my_root to the names of all the loggers. But then, my "root" logger my_root is still the child of the real root logger, and I can't switch my_root to DEBUG without also switching the root logger to DEBUG (as far as I understand), which I don't want to do. Is there a (preferably elegant) way to get what I want?
I guess the equivalent question is, can I set a child logger's level lower than its parent logger?
Related
in my project i am using the logging module and write the logs into a local .log file, in addition i want to pass the same log to another function to document locally the logs with circular queue algorithm.
it is possible to configure the logger to do it?
thanks .
the currnet logging config
logger=logging.getLogger(__name__)
logger.setLevel(logging.DEBUG)
formatter=logging.Formatter("<SOME FORMAT>")
file_handler=logging.FileHandler('logfile.log')
file_handler.setFormatter(formatter)
logger.addHandler(file_handler)
!! UPDATE : SOLVED - #imriqwe answer here https://stackoverflow.com/a/36408692 helped me to figure it.
I think this thread Python logging to multiple handlers, at different log levels? answers your question, it shows how to add multiple handlers, one file handler and one stream handler.
I see different ways to use Structlog and I was wondering what the exact difference is.
Let's say I want to log something using Structlog, you could for example use:
logger.msg("My log message")
But there are other ways to log, like info, debug (as in the standard Python logging library) which give you the possibility to say something about the importance of a message (which you can filter using loglevel):
logger.info("This is an info message")
logger.debug("This is a debug message")
The question is: what is the advantage of using logger.msg as compared to the other ways to log like info and debug? Why would I choose logger.msg?
msg() is a remnant from the original generic BoundLogger that tried to have both stdlib and Twisted log methods (msg() hailing from the Twisted end).
If you use structlog's internal filtering system via structlog.make_filtering_bound_logger(), it's equivalent to the info log level.
You can safely ignore it.
I am trying to test my config files by validating them, nothing fancy, a schema, a list of envs, iterate over it, load the config and validate the variable against the schema.
Problem is, to do that, I currently have to set process.env.NODE_ENV. Since the tests have their own reserved config file, this mean if the tests were run in parrallel, it may happen that the test change the NODE_ENV variable when the other tests are loading the config, which while it doesn't seems likely to happens, still bother me.
A simple solution would be to be able to tell node-config to ignore the environment variable, and use a given value as if it was, something like require('config')('myNodeEnv'), but I couldn't find anything similar in the wiki nor the documentation. The closest is custom env variable, but this would just move the problem to another variable.
Instead of tests having their own config files, tests should load a same "base" test-config.
When a specific test needs to override a specific value it should override that specific value and not the entire config (needless to say, we need to make sure to fix the overridden value when the test finishes).
When we work as described above, it reduces the chances of any collision because the chances that different tests will override the exact same value at the exact same moment is very low.
Another option is to run tests separately, for example:
npm run test:suite1
npm run test:suite2
where test:suite1 could be declared in package.json under scripts section, for example:
"test:suite1": "NODE_ENV=test-conf-1 tests/suite1.js",
...
I'm using hs.logger and the default behaviour is to display only the WARNING Level by default.I would like to set it to DEBUG or INFO when I'm developping locally... I found this function hs.logger.defaultLogLevel on the documentation (http://www.hammerspoon.org/docs/hs.logger.html#defaultLogLevel) but I'm not able to find this function in the Library ! If you think there is a better Library to use in haskell, please say it to me as well :-)
I have no experience with hslogger, but this part from the docs seems relevant:
-- Now we'd like to see everything from BuggyComponent
-- at DEBUG or higher go to syslog and stderr.
-- Also, we'd like to still ignore things less than
-- WARNING in other areas.
--
-- So, we adjust the Logger for MyApp.BuggyComponent.
updateGlobalLogger "MyApp.BuggyComponent"
(setLevel DEBUG)
-- This message will go to syslog and stderr
debugM "MyApp.BuggyComponent" "This buggy component is buggy"
What I mean by this is:
I have a program. The end user is currently using it. I submit a new piece of source code and expect it to run as if it were always there?
I can't find an answer that specifically answers the point.
I'd like to be able to say, "extend" or add new features (rather than fix something that's already there on the fly) to the program without requiring a termination of the program (eg. Restart or exit).
Yes, you can definitely do that in python.
Although, it opens a security hole, so be very careful.
You can easily do this by setting up a "loader" class that can collect the source code you want it to use and then call the exec builtin function, just pass some python source code in and it will be evaluated.
Check the package
http://opensourcehacker.com/2011/11/08/sauna-reload-the-most-awesomely-named-python-package-ever/ . It allows to overcome certain raw edges of plain exec. Also it may be worth to check Dynamically reload a class definition in Python