New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
logging: allow multiple entries in qualname config #55338
Comments
When configuration is specified in external file, qualname attribute should allow several values. Maybe comma separated. |
There's no particularly good use case for this. Plus, going forwards, dictionary-based configuration should be used (as it supports more logging features). |
Where is this configuration? |
See PEP-391. Documentation is at http://docs.python.org/library/logging.html#configuration as you might expect. |
And how do you intend to parse the dictionary stored in external file? Evaluating this script is unsafe. |
The logging package will not parse any external file to get a dictionary. It's up to the application developer to provide a dictionary which will be used for configuration, so there's no security issue in the stdlib. |
Hello friends, @vinay.sajip - the use case for this feature is actually something I come across fairly often. In an application I have dozens and hundreds of logger instances. However, they all fall into one of several loggers. Most of the instances are obtained through a module-wide logger = getLogger(name). Now I have a feature in the application split over a couple of modules, in different namespaces: zato.common.scheduler They are independent yet related and it would be most convenient if I could list both in qualname - they really should share the logging configuration, at no point they should have separate handlers, logging formats, anything. As an aside, regarding dict configuration - I know you made the comment in 2011 so it may not represent your current opinion but please keep in mind that logging config is something that on production is updated by administrators, i.e. whatever the latest trends in software development are, they aren't necessarily programmers. People I work with have no problems with customizing ini-like files but Python dicts are an entirely different story, they are simply afraid of doing it - a missing apostrophe may mean a couple of hours wasted, for instance. |
Well, that's easy enough to do - although there would be some duplication in the .ini file, it is not especially onerous. While I well understand the benefits of DRY, I still don't believe this is a very common use case, and there are other ways of doing this: for example, using a logger called zato.scheduler from both scheduler modules. I know that __name__ for naming loggers is a good approach in almost all cases, it's not absolutely mandatory. What I don't want to do is to keep adding functionality (which I will then have to maintain) to an older mechanism when a newer and better one is available. And using dictConfig() doesn't have to mean users/administrators editing Python source code by hand - for example, YAML could be used, or JSON. Or, use .ini but parse the file in your code and build a dict to pass to dictConfig(). Then you can use any schema you want, plus support things like Filters which fileConfig() doesn't do. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: