On 12/11/2010 1:28 AM, Vinay Sajip wrote:
Nick Coghlan<ncoghlan<at> gmail.com> writes:
The "lazy" stream handler might be useful to make public in some way.
For example, rather than hardcoding sys.stderr, it could take a
callable that it uses to retrieve the stream. That kind of change can
wait until 3.3 though - what is there now should be fine to let us get
concurrent.futures and the logging tests to play nicely together.
Actually if we're to change things to print INFO to stdout and WARNING+ to
stderr, I'd change the last resort handler class to be more than just defining
a lazy stream property: perhaps something like [untested]
class _DefaultHandler(StreamHandler):
def __init__(self, level=NOTSET):
"""
Initialize the handler.
"""
Handler.__init__(self, level)
def emit(self, record):
if record.levelno == INFO:
self.stream = sys.stdout
else:
self.stream = sys.stderr
super(_DefaultHandler, self).emit(record)
So I think Nick's configuration stuff is something that is supposed to
be done by the application, not by the library, or am I missing that
too? And so if it is done by the application, then Nick's, or any other
application writer's, preferences for where to send which messages can
likely be accommodated. But I think that by default anything that is
not part of the application's defined output, should go to stderr...
even INFO messages. I have no problem with Nick wanting them on
stdout, but I would have a problem with libraries (or the logger of
last resort) sending them there by default.
As far as whether anything else in the logging defaults needs to
change, I don't think so. I'm now happy that if an application needs
I agree it can be refined later, but if we agreed that INFO goes to stdout,
then something like the above could be put in place for 3.2 (perhaps 3.2b2).
I'd find that hard to agree to, but I probably don't count. I like
Nick's statement. Libraries spewing messages to stderr is fine, spewing
them to stdout is not, by default.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
