Logging vs printing

Leo Breebaart leo at lspace.org
Mon May 8 14:55:46 CEST 2006

Sybren Stuvel <sybrenUSE at YOURthirdtower.com.imagination> writes:

> Leo Breebaart enlightened us with:

> > I think the main reason why I am not using [logging] by
> > default is because, when all is said and done, it still comes
> > easier to me to resort to guarded print statements then to
> > set up and use the logging machinery.
> The logging "machinery" isn't that huge nor is it difficult to set up:
> ==================================================
> import logging
> logging.basicConfig()
> log = logging.getLogger('your.module.name')
> ==================================================
> and that's all there is to it.

I did say: "it comes easier *to me*" -- I am aware that my own
tastes, which may not be shared by others, or be entirely
logical, feature into this.

Having said that, I do think it's also not *quite* as trivial as
you claim. In order to duplicate what I already have ("if config.verbose:
print msg"), I probably need to log at the DEBUG level, and I
need to change the format so that that output looks like the
'print' output (no timestamping cruft etc.)

Okay, you say, that's still easy. It's just:

logging.debug('A debug message')

And that's true, but I did have to go and look this up, and I
made a couple of false starts first. I can only repeat that the
workings of the logging framework are rarely intuitive to me.

Also, assume that I have set it up as above. Now I want certain
other print statements to go to sys.stderr alone. If I understand
the docs correctly (possibly I don't), the way to do this is to
start attaching explicit StreamHandlers and whatnot. Whereas with
print, I can say "print >>sys.stderr, msg".

I know that it won't take much for a script to become so complex
that the extra stuff logging buys you vastly overpowers the
convenience of the print statements. I have just not needed that
often enough for it to become second nature to use in smaller
scripts as well.

Leo Breebaart  <leo at lspace.org>

More information about the Python-list mailing list