Logging cf Reporting = Friday Filosofical Finking

[DL Neil]

Is logging an unpopular package?
Is extending its use, as described, 
interesting/inappropriate/illogical/downright-crazy?


On 5/04/19 8:34 AM, DL Neil wrote:
> 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