Logging cf Reporting = Friday Filosofical Finking

[DL Neil]

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