[Python-Dev] PEP282 and the warnings framework

[Vinay Sajip]

[Steven Lott]
> ouch.  That is too cumbersome to be an essential feature.  When
> debugging a fairly sophisticated class, some methods deserve
> their own subjects.  This would be awfully complex to create a
> channel/logger instance for each interesting method.

I'm not suggesting that you need to create a logger for every method.
Remember, you can already see which module/file and the line number where
the logging call was made. If you wanted more information, you could easily
include it in the logging message - this could either be the whole of the
subject, or include the subject.

> It would be much more useful to have a
> A) truly Singleton logger instance.

Different people have different needs. You can just use the root logger.
Others can create more loggers if they want.

> B) the ability to specify subject, severity, etc. as part of
> the object being logged; via a simple log.log() method that
> accepts an Event instance.  A default subject would be used for
> people who didn't provide one in the constructor.

I understand why some people might like this, but I don't think it's
everyone's preferred way of working. The successful logging systems which
inspired PEP282 do not force one to instantiate a class for the simple case.
My other posts indicate how some support for your needs might be provided,
without forcing everyone down the same path.

> C) the ability to use method names or arguments to fill in part
> of an Event object; log.warn(), for example would fill in the
> module-specified warning severity;
> log.log(...,severity=logging.WARN) for those who prefer fewer
> methods with more options.

logging.py already uses convenience methods to fill in the level. Have you
looked at the module yet, or am I misunderstanding?

> D) the ability to create an Event object out of a standard
> Exception instance (filling in subject and severity
> automatically)

What do you mean by "create out of"? If you mean "inherit from", I disagree,
as not all events are logically exceptions (e.g. informational events). If
you mean "have as an attribute", then that's supported by existing
mechanisms. "Filling in subject and severity automatically" - I can just see
a plethora of disagreeing views over what severity should be used for this
exception or that.

Of course, all of this is possible by building on the core framework. I'd
hope I've tried to make "simple things easy, and hard things possible".

> E) the ability to construct a "this class" or "this module"
> accessor as shown above that would fill in the subject for
> people who found the "channel" model helpful.
>
> Items A-D would be the core logger, maximum flexibility, minimal
> implementation.  Item E would add a feature to the above model
> that some people find useful.

If you ask me, logging.py is fairly minimal when compared to (say) log4j.

log4j  - 24 source files, 7000 lines, over 200Kbytes - core logging +
console and file handlers
logging.py - 1 source file, under 2000 lines, 7Kbytes, core logging +
console, file, socket, datagram, and other handlers. I have considered
moving some of the less used loggers out of the core, but even with them in
it's still pretty small. No, don't all disagree at once!! Just trying to
show off :-)

Regards

Vinay



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com