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

Nick Coghlan ncoghlan at gmail.com
Sat Dec 11 09:35:29 CET 2010

On Sat, Dec 11, 2010 at 4:18 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:

formatting (when the documentation for the new styles feature goes in would probably be an appropriate time to fix this). Similarly, the Sorry, what do you mean by "new styles feature"?

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.

Anyway, the shortest way I could find of setting this up (debug Yes, except that you could have set the root logger level to INFO rather than DEBUG. This raises some more questions. Obviously, we don't want users to have to go through these steps themselves. Once these steps have been finalised, the last resort handler could be modified to do all this. Should this handler be part of the public API, so that it can be inherited from 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.

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 to emit text on stdout as part of its normal operation, then that isn't what the logging module is for - logging messages are intended to record "this happened, then that happened, then this other thing happened". They are not properly part of an application's console UI (which is reflected in the whole "silent by default" and "console 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.

I realise we're in beta and hence feature freeze ... just sayin'. We're all consenting adults here, after all :-)

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.

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.

Cheers, Nick.

[1] http://code.activestate.com/recipes/577496-simple-creation-configuration-and-installation-of-/

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list