Is the logging module an ideal means to provide (printed) user reports,
or is it a 'bad fit' and not designed/fit for such a purpose?
PSL's logging module (per discussion 'here' earlier this week) is often
quietly avoided by 'the average Python programmer'. It is unwieldy, yet
that is, in-part, a function of its power and flexibility. Its
explanation in the Library docs requires multiple pages - and even after
sending us first to the 'HowTo', still many people turn away (vaguely
promising to 'come back later'). For the nit-picky amongst us: it
dramatically fails PEP-8* (and we won't even mention higher numbers).
Once the framework is learned, its flexibility appreciated, and its
strictures accepted; (IMHO) the library comes into its own. Over the
years, the range of output options ("handlers") has grown and become
ever more sophisticated. Simple text files are now supplemented by
"rotating" mechanisms; simple socket transmissions have formalised into
SMTP (email), HTTP, queues, and datagrams; and both MS-Win and *nix
syslog mechanisms are covered. Similarly, the traditional formatting of
messages with ToD-clock, technicalIDs, and error-level preceding the
'real content', whilst still standard, can be completely replaced to
suit the application and circumstance.
The received-wisdom of text books and tutorials is that Python trainees
should 'evolve' from using quick-and-dirty debug-print functionality, to
logging. This idea(l) promotes the virtue of providing a full
information flow when it is vitally-needed, but not cluttering-up the
display with excessive and extraneous data, when not - especially when
GUIs are involved! (plus obviating that pesky-business of going-through
ensuring every debug-print is deleted or commented-out, before delivery
to 'live'!) However, there's always a lot to learn - too many toys, too
little time!
Recently, I was building a little "batch job"# for an author-friend
who'd lost control of his extensive and burgeoning library of files,
back-ups, half-dead disks, archives... Being a 'good boy'& I was
throwing all the debug/test/demo info out to a log-file. Without (my)
thinking too much, all the useful listings ended-up in the same place.
Oops! Rather than bringing them 'back' out to the screen (which, because
he prefers to work from paper rather than the screen - "now you tell
me". Sigh!) would also have meant capturing sys.stdout to grant the user
his (late-expressed) desire; I established another logger and made minor
mods to the code so that it would instead emit the 'useful' output
there. Hence, an "output report".
I was chuckling at how my 'mistake' turned into a 'plus', because
without a lot of work to 'fix' things, the user was given exactly what
he wanted! ("oh, and it would be nice if you could send the file to me
by email..." - they're always, um, never, (quite) satisfied...)
In the more general case, when at least some of an application's output
goes to file (or similar), is it a 'smart move'% to use the logging
library to collect more than behind-the-scenes debugging, or
application/syslog-level data?
* but then, so do I!
# https://en.wikipedia.org/wiki/Batch_processing
& if you believe that, you'll believe anything!
%
https://www.quora.com/What-is-meant-by-the-Mark-Twain-quote-To-a-man-with-a-hammer-everything-looks-like-a-nail
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
