Improving logging, was Re: Optional use of logging library module
vinay_sajip at yahoo.co.uk
Mon Jul 5 15:54:05 CEST 2004
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.
More information about the Python-list