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

Paul Moore p.f.moore at gmail.com
Wed Dec 8 14:19:26 CET 2010

On 8 December 2010 12:15, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:

The Java thing is a red herring, I believe. It's more akin to the Unix idea of minimum verbosity as a default.

And yet Unix invented the concept of stderr, precisely to ensure that there's a route for things the program wants to inform the user about to get out.

The NullHandler approach could be seen as the equivalent of adding 2>/dev/null to every command by default.

In general, you don't need to "configure a library" except when you want specific behaviour from that library's loggers.

The "specific behaviour" I want is for errors and warnings to go to stderr. Every time. (Unless I'm writing a service that wants to redirect all output to a log file, or something like that - and that's where I'm really glad to have the logging module! And the fact that the defaults tend to encourage library authors not to use it really frustrate me as an applicatioo developer.)

I'm not opposed to changing the way things work, but I think we need more of a consensus because some backwards incompatibility will result, albeit not likely to affect too many users of logging.

Hmm. As far as I can tell from reading the thread, everyone but you is in favour of errors and warnings going to stderr by default. I may have missed some dissenting views, but it certainly feels like a consensus to me!

If you feel that the proposal needs to be presented to a wider group than just python-dev then that's fair. But personally, I think that python-dev will be a reasonably good indicator in this case.

For a comparison, the warnings module logs all warnings by default on stderr without requiring any a priori configuration. And that's what stderr is for (reporting errors).

But that behaviour is not always wanted. That's why I was asked to add warnings integration to logging - to redirect warning messages to logging. Things are seldom as black and white as you're making them out to be here.

Exactly!!!! Logging should be a BETTER option than direct writes to stderr. At the moment, though, it's a CHOICE - writes to stderr, which are visible by default but (very) inflexible, or logging which is flexible but suppressed by default (OK, "if you follow the recommended practice to avoid a user-hostile warning"). The problem is that some people are voting with their feet that visibility matters more than flexibility.

Indeed, this is convenient. And that's what I'm arguing should be the default for all loggers, not just the top-level one. There's no reason that what is convenient for the root logger isn't for other loggers. Loggers work in a hierarchy, and the package is specifically designed so that you can attach handlers just to the root logger, and get messages from all code in your application + its libraries to destinations that you configure there. This is not special case behaviour for root logger versus other loggers - it's just that the root logger is a convenient, logical place to attach handlers.

But you don't because the library developer added a NullHandler which you have to switch off!!!

Hey, that's not why I think "not too inconvenient"! It's because

(a) It's no less inconvenient than "import foo", and it's hard to argue that one line is really inconvenient for this case - remember, for the simplest uses you can omit the basicConfig() call, since you can use logging.info() etc. (b) For this case, since there's no telepathy in this world, you need some way for the programmer to communicate their intent about the logging level, or format string, or log file that they want to use. I stand by the statement that one line (or more precisely, one function call) is not too much to ask here, so yes - "not too inconvenient". That's emphatically not because I'm the module's author and "used to it".

FWIW, basicConfig has never been what I want. Except in the sense that I have to use it to switch on logging to stderr (if only it worked, but see the comment above about NullHandler) because that's not the default. In all other cases, I've wanted a little bit more (which may not be hard to achieve, but that's not the point here).

Saying that's convenient is like saying that adding sys.stderr=open("/dev/tty", "w") is a convenient way of getting errors displayed when you don't like the default destination of /dev/null.

Paul.

More information about the Python-Dev mailing list