[Python-Dev] Using logging in the stdlib and its unit tests

[Glenn Linderman]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20101211/4b5c6786/attachment.html>