improvements for the logging package

[Trent Mick]

[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.

Fair enough. I'm all for having consistent and well structure code in
the stdlib.


>     >> import logging
>     >> logging.info('hello world')
>     >> 
>     >> ought to just work (implicitly add a stream handler connected to
>     >> stderr to the root logger).
> 
>     Trent> Maybe. Unless that causes troubles for real use. 
> 
> 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.
> 

Unfortunately your getting caught by the default logging level being
WARN, so that any log level below that is tossed.

    import logging
    logging.basicConfig()
    logging.error("help!")
    logging.warn("stay away from the river")
    logging.info("nice sunset, eh?")

Running that generates:

    ERROR:root:help!
    WARNING:root:stay away from the river

>     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.

Sort of. I guess all it implies is that if application code wants
to do special log handler setup then it needs to make sure to work in
the case of basicConfig() having been called and not.

The configuration stuff is quite subtle. The docs need to give
good best practices for a could coverage of reasonable use cases.
Nothing catastrophic will happen with a weird logging configuration --
probably just more log messages that you'd want.


> It was probably the log4j roots that provided the non-PEP 8 naming.

Definitely.

> I suspect the naming could be improved while providing backward
> compatibility aliases and deprecating those names.

Do you mean naming like "makeLogRecord" etc? I thought PEP 8 said
camelCase (or whatever it is called) was okay?


Trent

-- 
Trent Mick
TrentM at ActiveState.com