Improving logging, was Re: Optional use of logging library module

[Vinay Sajip]

Peter,

Thanks for the feedback. My thoughts below...

> - A one-stop function to get output to a file or stream.

Now in CVS.
 
> - A standard way to register custom handlers, something like
> registerHandlerClass(klass, name=None), name defaulting to klass.__name__.
> This would probably imply replacing eval() with a dictionary lookup.
>
> - I find the programmatic interface easier to learn than the config-file
> format. A utility function that writes the current configuration to a file
> might help here.
>
> - Let config-files and programmatic setup respect each other.
>

The above are good ideas. By "respect each other", I assume you mean
that file-based configuration should not overwrite programmatic
configuration? The overall problem with file-based configuration is
that it replaces the existing configuration totally. I'm thinking
about a different way of configuring which works in an incremental
way. It's too early to say much about it, though.

> - Allow for multiple root loggers. Logging can be used for totally unrelated
> tasks. I feel a little uneasy to have them all in the same hierarchy. (This
> one is thinking aloud, I'm not even sure if this cannot be done already
> with the Manager class) 

I'm not sure that you need API changes for this - you can achieve the
same effect through non-propagating non-root loggers. Since you can
direct messages at any point to any destination, you can easily keep
totally separate logs for unrelated tasks.

> None of these are showstoppers, and judging from recent posts on python-dev
> you are already working on the first and most important issue.
> 
> If you want to attract further suggestions on how to smoothen the logging
> experience, from people who are more familiar with the package than I am,
> it would probably be a good idea to open up a new thread.
> 

Good idea. I'll do this.

Thanks again,


Vinay