On Jul 15, 3:04 pm, Matthew Wilson <[EMAIL PROTECTED]> 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
> configurations.
>
> 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
> file?
>
> MattThe 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 configuration. 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. Best regards, Vinay Sajip -- http://mail.python.org/mailman/listinfo/python-list
