improvements for the logging package

skip at pobox.com skip at pobox.com
Tue Sep 6 23:08:50 EDT 2005


    >> while working on something in my current project I have made several
    >> improvements to the logging package in Python, two of them are worth
    >> mentioning:
    ...
    Trent> Cool. Your additions sound useful.

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.

(*) 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).

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

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

Skip



More information about the Python-list mailing list