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

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