improvements for the logging package

[Vinay Sajip]

skip at pobox.com wrote:

> Perhaps so, but the logging module seems like such an unpythonic beast to
> me.  How about cleaning it up (*) before we add more to it?  Stuff like
> colorizing seems like it belongs in its own module (presuming a reasonably
> general markup scheme can be agreed upon) so it can be used outside the
> logging package.

How is it unpythonic, exactly? I agree that colorizing, etc. is
probably best located in its own module.

> (*) Stuff that seems very odd to me:
>
>     - It's a package, but contrary to any other package I've ever seen, most
>       of its functionality is implemented in __init__.py.  __init__.py is
>       roughly four times larger than the next largest (bsddb, which is a
>       beast because BerkDB has gotten so big over the years and the
>       module/package has strived to remain backwards-compatible).

I agree that __init__.py is rather large, but I wasn't aware of any
guidelines restricting its size. Having a smaller __init__.py and e.g.
putting the bulk of the code in a subpackage such as logging.core was
considered; I didn't see the point of doing that, though! And the
module certainly received a reasonable amount of peer review on
python-dev before going into the standard library.

>     - It's still too hard to use.  The obvious 'hello world' example
>
>         import logging
>         logging.info('hello world')
>
>       ought to just work (implicitly add a stream handler connected to
>       stderr to the root logger).

As Trent pointed out in another post, one extra line with a
basicConfig() call would provide the behaviour that you want. This is
surely not too much to have to add. The default level of WARNING was
deliberately chosen to avoid excessive verbosity in the general case.

>     - 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's in
>       (you have three guesses and the first two don't count) __init__.py
>       instead of in logging.handlers.  Consequently, browsing in the obvious
>       way fails to find the StreamHandler class.

It's partitioned that way so that the most commonly used handlers are
in the core package, and the less commonly used ones are in the
handlers package. This seems reasonable to me - you don't incur the
footprint of the less common handlers just to do console and file based
logging.

>     - 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.  Eschewing PEP
>       8 is fine for other stuff, but code in the Python core (especially new
>       code like the logging module) should strive to adhere to PEP 8, since
>       many people will use the core code as a pattern for their own code.

I would not have been too unhappy to change the naming to unix_like
rather than CamelCase. Nobody on python-dev asked for it to be done.
The code was mostly written before the idea of putting it into Python
came up - Trent had independently written PEP-282 and I had done a fair
amount of work on the module before getting the idea that, by adhering
to PEP 282, it could be put forward as an addition to the Python
standard library.

Regards,

Vinay