[Python-Dev] Using logging in the stdlib and its unit tests (original) (raw)

Vinay Sajip vinay_sajip at yahoo.co.uk
Sat Dec 11 10:28:14 CET 2010

Nick Coghlan <ncoghlan 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

More information about the Python-Dev mailing list