[Python-Dev] Re: PEP 282 comments (original) (raw)

Jeremy Hylton jeremy@zope.com
Fri, 22 Mar 2002 11:38:55 -0500

"VS" == Vinay Sajip <vinaysajip@red-dove.com> writes:

VS> But I think we all neglected to see that by implementing VS> exception with one extra argument, the whole controversy goes VS> away. Just remove logException and change exception so that it VS> becomes

VS> def exception(self, level, msg, *args): VS> """Use when handling an exception""" if VS> self.enabledFor(level): VS> self.log(level, 1, msg, args)

VS> We've effectively renamed logException() as exception(). There's VS> not a lot to choose between

VS> logger.exception(INFO, msg, args)

VS> and

VS> logger.exception(msg, args)

VS> If people can't stomach having to put the level into every call VS> to exception, then we can keep exception as it was [syntactic VS> sugar] and reintroduce logException (perhaps change the name, VS> it's a bit of a sore thumb).

The thing I like best about PEP 282 is the method names that indicate the log levels. While it's just a convenience, it's a handy one. It saves me having to explicitly manage my namespace to make those names visible. The Zope code base is littered with "from zLOG import LOG, INFO, DEBUG" lines. If I find a place where I need to add a TRACE message, I have to remember to check the import line to see if that name is bound. I've forgotton on more than one occasion, and since it's on an unusual code path, I don't find out until it fails at runtime.

Now we can just use "import zLOG" and name everything explicitly, but that makes for a lot of extra typing:

zLOG.LOG("Channel", zLOG.TRACE, "a trace message", exc=sys.exc_infO())

Now this is only a minor annoyance, but I'd be happier with the shorter and equally clear version

log.trace("a trace message", exc=sys.exc_info())

VS> If any more syntactic sugar is wanted, then I think it's VS> reasonable for people to roll their own classes.

I guess the question is how many users want this. If many users like this feature, we end up forcing everyone to roll their own classes. I don't have a good intuition about what the typical user of a logging module will want. Can log4j teach us anything?

VS> some users want to use their own levels, no doubt for their own VS> good reasons. The current implementation supports this. They can VS> use log() and logException(), but debug(), info(), warn(), VS> error(), fatal() and exception() are useless to them - and so VS> exposed as the syntactic sugar they really are. So if users VS> really want, they can define a level BAD_HAIR_DAY and a VS> corresponding sugar method bad_hair_day(self, msg, *args) which VS> calls either log() or logException(), as they please. It's not a VS> job for the standard module, I'm sure all would agree.

I agree. I also expect that most users will just use the standard levels.

Jeremy