[Python-Dev] Re: PEP 282 comments

[Jeremy Hylton]

>>>>> "VS" == Vinay Sajip <vinay_sajip@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