Derek Wilson added the comment:
> It's not an ideal world. Sorry, but I think this change is too invasive to
> consider.
Obviously its not ideal, which is why my suggestion doesn't require intelligent
3rd party libraries and is explicitly not invasive. As I said in my previous
comment, using
Derek Wilson added the comment:
dictConfig and fileConfig are nice for static needs, but when I want to quickly
enable a complex (but not complicated) logging flow I find it just as tedious
as the current situation with the direct API.
... as at the very least every handler would need to be
Vinay Sajip added the comment:
If 3rd party handlers are intelligent
It's not an ideal world. Sorry, but I think this change is too invasive to
consider. I can't believe this change is really needed - logging has been
around since 2002 and this has never been raised before.
--
Vinay Sajip added the comment:
I suggest that the declarative configuration approach of
logging.config.dictConfig() be used for configurations which can't be handled
by basicConfig().
I don't propose to enhance the Handler API as suggested, as at the very least
every handler would need to be
New submission from Derek Wilson:
It is common when setting up a logger to create both a handler and a formatter.
Nice format strings make logging better. Like this:
fmt_string = %(asctime)s [%(levelname)-9s] %(name)s: %(message)s
We would use it like so:
from logging import getLogger,
