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

[Vinay Sajip]

Nick Coghlan <ncoghlan <at> gmail.com> writes:

> The switching between percent, str.format and string.Template
> formatting. It turns out that has been documented, but the table in
> question is still written from a percent-style formatting point of
> view.

Oh, right - yes. I presume you mean the table in the formatter documentation
which shows %(message)s etc.
 

> 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)

> 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).
 
> output defaults to sys.stderr" philosophy). The change to the default
> behaviour was just to make logging.warning() etc a suitable
> replacement for writing directly to sys.stderr when exceptions can't
> be raised, which is in keeping with the existing spirit of the logging
> module.

Agreed.
 
> I don't think we should be adding more *code* at this stage. But
> documentation fixes and adjustments may be a good idea. I've learned
> quite a bit myself about the logging module in the course of this
> discussion, so it would be nice if some of that could be captured and
> used to improve the documentation.

Yes, you (and Glenn, and others) have given me quite a bit to work on, on that
score!
 
> That said, something that might be interesting is to see what my
> addHandler() recipe [1] would do for the examples in the logging
> documentation. If it makes a big enough difference, then it may be
> worth talking to Georg about adding it, even for 3.2. Alternatively,
> if you like the idea, but we don't want to break the feature freeze
> for it, then it may make a nice "see-also" link from the docs. I find
> it useful from a "here are all the things I can configure on a handler
> in one easy bundle" point of view, even aside from any benefits in
> reduced typing.

Actually I've been thinking about a handlers= optional argument for basicConfig
for some time (which, if provided, would override file and stream arguments).
But it seemed a little unwieldy and came across plainly as the afterthought it
admittedly was :-)

Regards,

Vinay Sajip