Tarek Ziadé <ziade.ta...@...> writes:
> I think logging is fine, but it misses a few pythonic functions on the
> top of it to work with.
>
> Right now, if you want to set up a logging output on a file or on
> stdout with some options,
> you have to write 5 or 6 lines of code.
There's basicConfig, which can be used like
logging.basicConfig(level=logging.DEBUG,
format='%(asctime)s %(levelname)s %(message)s',
filename='/tmp/myapp.log',
filemode='w')
for a file and
logging.basicConfig(level=logging.DEBUG,
format='%(asctime)s %(levelname)s %(message)s',
stream=sys.stdout)
for stdout. This configures the root logger, but you could obviously add a
loggerName argument that configured and returned a configured logger with that
name. That wouldn't even break backward compatibility.
It's not in general a desirable pattern to have handlers associated with every
logger - which is why I haven't provided that additional argument. It's more
common to attach handlers at the root and at certain specific points in the
hierarchy - for example, attach an SMTP logger to the root module for a
subsystem so that emails about errors can be sent to the team looking after that
subsystem.
Of course it's perfectly valid to have handers attached to multiple loggers -
but if you do that for lots of loggers, you get multiple messages and increased
processing time. If that's what is wanted, fine - it's just not the norm. But
having a convenience function which makes it too convenient to configure
multiple handlers could lead to lots of "I'm getting messages multiple times,
please help!" traffic on c.l.py.
The basic premise is - loggers map to areas in the application ("Where did it
happen?") and handlers to the audience ("Who wants to know?"). Apart from in
scripts intended to be run from the command line, in general you don't find a
one-to-one mapping between loggers and handlers.
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
