logging module example
smitty_one_each at bigfoot.com
Sat Dec 31 21:01:03 CET 2005
>>>>> "Diez" == Diez B Roggisch <deets at nospam.web.de> writes:
Diez> Chris Smith schrieb:
>> Hola, pythonisas: The documentation for the logging module is
>> good, but a bit obscure. In particular, there seems to be a
>> lot of action at a distance. The fact that getLogger() can
>> actually be a call to Logger.__init__(), which is mentioned in
>> para 6.29.1, also bears stressing on 6.29. I grasp _why_ you'd
>> implement it that way, but I may not be the only coder who
>> feels queasy with the word 'get' being used both to fetch an
>> instance and to trigger instantiation.
Diez> The reason for this "distance" is simply that you should be
Diez> able to get a grip on a logger from wherever you are,
Diez> explicitly _without_ first having to instantiate it and
Diez> possibly pass it around. Think of this little example:
Diez> So the decoupling makes lots of sense in logging IMHO.
Absolutely. The fact that it does eventually make sense, however, doesn't
preclude a bout of confusion at the fact that some_lager didn't
already exist before
pint = logging.getLogger( some_lager )
and that the logging module will merrily brew some_lager on the spot.
I submit that the documentation might be improved by including your
example on 6.29, gearing the neophyte up for how this (can we agree it
operates on slightly different principles than most?) module operates.
>> Anyway, after poring over the documentation, unit test, and
>> source code, I'd like to show a sample script that will
>> eventually be used in my vanity project, with four loggers of
>> increasing granularity. I realize there are probably more ways
>> to do this (logging seemingly sporting perl-esque flexibility
>> ;) so please weigh in with thoughts. Perhaps now I can go back
>> and get this to work with the logging.config interface. :)
Diez> That looks as an misunderstanding or somewhat strange usage
Diez> of the logging-api. It is _very_ uncommon to have loggers
Diez> level depending on _data_. Instead you just invoke
Diez> and set the level elsewhere. That is a somewhat static
Diez> releationship - all forests are supposed to share _one_
Diez> logging instance, with it's current log-level. And you don't
Diez> check for the level being DEBUG or whatever. You just log,
Diez> and if the level is above (or below, whatever stance you
Diez> take) the currently set level for that logger, the message
Diez> gets displayed.
My use-case is a desire to interpret an input file, and log traces at
varying output depth. I used the default labels, just to keep the
sample script small. However, I will (once I have grokked
that corner of the module more fully) follow your advice there, for
I'm really only talking about four densities of debug information.
Thank you for this feedback.
Diez> All in all it seems that you have some difficulties with the
Diez> loggers being a sort of global objects. Keep that in mind
Diez> when developing using them.
Yep, got to play the tune sloppy a few times before it's tight.
Nochmals vielen Dank. :)
More information about the Python-list