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

[Nick Coghlan]

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