improvements for the logging package

[Vinay Sajip]

skip at pobox.com wrote:

> >> - It's a package, but contrary to any other package I've ever seen,
>     >>   most of its functionality is implemented in __init__.py.
>
>     Trent> I'm not defending the implementation, but does this cause any
>     Trent> particular problems?
>
> No, it just seems symptomatic of some potential organizational problems.

Could you please elaborate on this point further? What sort of
problems?

> Maybe there's a bug then (or maybe the docs still need work).  When I
> executed (all of these examples were typed at an interactive prompt):
>
>     import logging
>     logging.info('hello world')
>
> I get no output.  Looking at the doc for the basicConfig() function, I see:
>
>     The functions debug(), info(), warning(), error() and critical() will
>     call basicConfig() automatically if no handlers are defined for the root
>     logger.
>
> If I read that right, my "hello world" example ought to work.  I tried:
>
>     import logging
>     logging.getLogger("main")
>     logging.info("hello world")
>
> and
>
>     import logging
>     logging.basicConfig()
>     logging.info("hello world")
>
> and
>
>     import logging
>     logging.basicConfig()
>     log = logging.getLogger("main")
>     log.info("hello world")
>
> Shouldn't one of these have emitted a "hello world" to stderr?  (Maybe not.
> Maybe I need to explicitly add handlers to non-root loggers.)
>
>     Trent> Having lazy configuration like this means that it can be a subtle
>     Trent> thing for top-level application code to setup the proper logging
>     Trent> configuration.
>
> Again, based on my reading of the basicConfig doc, it seems like the logging
> package is supposed to already do that.
>
>     Trent> I think the usability of the logging module could be much
>     Trent> improved with a nicer introduction to it (i.e. docs). It's not
>     Trent> really a "hello world" type of tool. Its usefulness only really
>     Trent> shows in larger use cases.
>
> I agree about the docs.  Whatever the "hello world" example is (I clearly
> haven't figured it out yet), it ought to be right at the top of the docs.

OK, it's not right at the top of the docs, but the example at

http://docs.python.org/lib/minimal-example.html

has been there for a while, and if you think it can be made clearer,
please suggest how.

> If logging isn't trivial to use, then many simple apps won't use logging.

I would contend that it *is* pretty trivial to use for simple use
cases.

> Consequently, when they grow, logging has to be retrofitted.
>
> It was probably the log4j roots that provided the non-PEP 8 naming.  I
> suspect the naming could be improved while providing backward compatibility
> aliases and deprecating those names.

Not directly - but I work all the time with Python, Java, C, C++, C#,
JavaScript environments, among others. In some environments, such as
Java, CamelCase is more or less mandated. So I tend to use
camelCaseMethodNames because then I don't have a cognitive
disconnection every time I switch languages; I don't have the freedom
to use lower_case_with_underscores everywhere. I certainly didn't copy
much beyond the ideas from log4j - if you compare the log4j
implementation with stdlib logging, you will see how Pythonic it is in
comparison (if you leave aside superficial things like the use of
camelCaseMethodNames). In any event, the commonest use of logging does
not require you to use much camelCasing - apart from basicConfig()
which is only called once.

Regards,

Vinay