logging module example

[Chris Smith]

>>>>> "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:

[snip]

    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. :)

[snip]

    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> logger.debug(some_data)

    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. :)
Chris