> [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.
>
[Vijay]
> 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.
I think your previous example showed that subject-level
filtering required a separate logger/channel per subject.
Is there another mechanism for subject tracking?
The point here is that subjects can (and often are) as
fine-grained as individual methods of a class. Sometimes
they are even more fine-grained when dealing with fairly
complex algorithms, although this is rare.
When I need fine-grained subjects management, I don't want
to have many logger/channel instances. I want to have one
channel with a subject attached to each loggable Event.
[Steve]
> > 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.
[Vijay]
> 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.
Agreed. My position is that an Event instance should be
created, even when someone uses the convenience methods
available under PEP282. The core function is to track
Events; even when done through convenience functions that
make it appear as though logging is simply tracking a string.
[Steve]
>
> > D) the ability to create an Event object out of a standard
> > Exception instance (filling in subject and severity
> > automatically)
[Vijay]
> What do you mean by "create out of"? If you mean "inherit
> from", I disagree,
[snip]
Agreed, loggable Events are not Exceptions, but the information
in a loggable Event would be derived from the attributes
of an Exception
The constructor for a loggable Event would accept an
Exception as an argument and create a new loggable Event
from the Exception's attributes.
[Vijay]
> "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.
[snip]
Precisely the point - severity is a difficult concept, not
core to the way logging works. It is only one of the many
attibutes of a loggable Event; the primary purpose of logging
is to accept Events, filtering them and pickling them for
future analysis.
The pickling can be by formatting for printing or by storage
to some other file system or RDBMS (or broadcasting through
a network or whatever).
[snip]
=====
--
S. Lott, CCP :-{)
S_LOTT@YAHOO.COM
http://www.mindspring.com/~slott1
Buccaneer #468: KaDiMa
Macintosh user: drinking upstream from the herd.
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4