Proposed changes to logging defaults

[Jean-Michel Pichavant]

Vinay Sajip wrote:
> 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
>   
Thanks for the explanation.

JM