improvements for the logging package

[skip at pobox.com]

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

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

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.

If logging isn't trivial to use, then many simple apps won't use logging.
Consequently, when they grow, logging has to be retrofitted.

    >> - Its functionality is partitioned in sometimes odd ways.  For
    >>   example, it has a handlers module, but what I presume would be the
    >>   most commonly used handler (StreamHandler) is not defined there.
    >> 
    >> - It doesn't use PEP 8 style as far as naming is concerned, instead
    >>   doing some sort of Java or C++ or Perl camelCase thing.

    Trent> Perhaps Vijay (who did all the implementation) can comment on
    Trent> these.  Unfortunately backwards-compat might restrict some
    Trent> cleanups to the package, but perhaps not too much. I did a poor
    Trent> job of keeping up with the package after I laid out an initial
    Trent> design, er copied an initial design from Java's log4j package
    Trent> (and I'm not even a Java guy). :(

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.