>> 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
--
http://mail.python.org/mailman/listinfo/python-list
