This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vinay.sajip
Recipients dsuch, techtonik, vinay.sajip
Date 2014-06-18.20:30:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1403123440.24.0.201040095649.issue11129@psf.upfronthosting.co.za>
In-reply-to
Content
> they really should share the logging configuration

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.
History
Date User Action Args
2014-06-18 20:30:40vinay.sajipsetrecipients: + vinay.sajip, dsuch, techtonik
2014-06-18 20:30:40vinay.sajipsetmessageid: <1403123440.24.0.201040095649.issue11129@psf.upfronthosting.co.za>
2014-06-18 20:30:40vinay.sajiplinkissue11129 messages
2014-06-18 20:30:39vinay.sajipcreate