Proposed changes to logging defaults

[Vinay Sajip]

On Dec 10, 10:17 am, Jean-Michel Pichavant <jeanmic... at sequans.com>
wrote:

Hi Jean-Michel,

I think Antoine answered your other points, so I'll address the last
one:

> Last question, if no handler is found, why not simply drop the log
> event, doing nothing ? It sounds pretty reasonable and less intrusive.

That is what happens at the moment if configured for production
(logging.raiseExceptions is False) - nothing happens, and the event is
discarded. For development (logging.raiseExceptions is True), the "No
handlers were found for logger XXX" is printed once, to assist
developers to detect misconfiguration. However, the original logged
event is still discarded.

The original philosophy (when logging was added to Python) was that
logging is an adjunct to the operation of the program using it - the
program should work the same way whether or not logging is configured.
However, the consensus on Python-dev is that the logging package
should do useful work, and not just act as an adjunct, i.e. notify the
user on warning and error conditions by default if no logging
configuration is set up. A program will now work differently depending
on whether logging is configured, but if it is not configured, the
default should be to display warnings and errors, unless explicitly
silenced (as per the Zen of Python).

These two approaches (original vs. proposed) are of course quite
different, and there's no way of satisfying both proponents of both
approaches, nor any easy way of measuring how many of each there are.
The proposed change moves logging closer to the current Python-dev
consensus, and means that messages currently written to sys.stderr by
stdlib modules could be logged instead, with the stdlib maintainers
writing those messages knowing that unless explicitly silenced, those
messages will appear to the user as they would via a
sys.stderr.write(). It will be good if this happens, so that
application writers will have better control over what messages are
displayed (when they need it), by configuring logging.

Remember - no changes to behaviour will occur if this change is
implemented and an application configures logging. It's only the no-
configuration case that will change.

To get the current behaviour after the proposed changes are
implemented, an application developer would have to do
logging.lastResort = None, which is a small price to pay (and more or
less equivalent in difficulty with what users who want verbosity by
default have to do, e.g. call basicConfig().

Regards,

Vinay Sajip