Logging cf Reporting = Friday Filosofical Finking
Is logging an unpopular package?
Is extending its use, as described,
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!