On Dec 10, 10:17 am, Jean-Michel Pichavant <jeanmic...@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 -- http://mail.python.org/mailman/listinfo/python-list
