How to package a logging.config file?
vinay_sajip at yahoo.co.uk
Wed Jul 16 01:31:37 CEST 2008
On Jul 15, 3:04 pm, Matthew Wilson <m... at tplus1.com> wrote:
> On Mon 14 Jul 2008 09:25:19 AM EDT, Vinay Sajip wrote:
> > Is your package a library or an application? If it's a library, you
> > should avoid configuringloggingusing a config file - this is because
> >loggingconfiguration is process-wide, and if multiple libraries use
> > fileConfig to configure theirlogging, you may get unexpected results.
> I thought that the point of usinglogging.getLogger('foo.bar.baz') was
> to allow each module/class/function to choose from the available
> So, I can define a really weird logger and still be a good citizen.
> As long as I don't tweak the root logger, is it safe to use a config
The reason why using fileConfig in libraries is problematic is that
fileConfig assumes it does the entire logging configuration. Whenever
fileConfig is called, any loggers which are not explicitly mentioned
in the config file (but are present in the logging system) are
disabled. (They are not actually removed, since there may be still-
running threads that have references to them.) You may think this is
odd, but it's only because fileConfig was never intended for
incremental configuration, only for a one-off configuration. So, a
fileConfig'd configuration is meant to completely replace the existing
So - you can use hierarchical naming of loggers to avoid stepping on
other loggers - for example, prefixing with the company domain name if
there's a possibility of use outside the company (in the same way as
Java packages use e.g. com.sun.XXX for Sun's proprietary Java
packages, or com.ibm.YYY for IBM's proprietary packages). However, I'd
advise against using fileConfig in library code, as it is likely to
disable already-instantiated loggers in other library packages.
More information about the Python-list