How to write verbose scripts

[Lie]

On Sep 3, 6:31 pm, Uwe Schmitt <rocksportroc... at googlemail.com> wrote:
> On 2 Sep., 18:55, Steven D'Aprano <st... at REMOVE-THIS-
>
>
>
> cybersource.com.au> wrote:
> > I find myself writing command line tools in Python where I wish to
> > include "verbose" output to stdout.
>
> > I start with a helper function:
>
> > def print_(obj, level=0):
> >     if _verbosity >= level:
> >         print obj
>
> > And then I end up with functions or methods looking like this:
>
> > def parrot(x)
> >     print_("precondition", level=2)
> >     do_something()
> >     print_("status is good...", level=1)
> >     print_("parrot is squawking strongly now", level=2)
> >     do_something_else()
> >     print_("squawk squawk squawk", level=3)
> >     do_more()
> >     print_("postcondition", level=1)
> >     return something
>
> > That often means that my functions end up with more message printing code
> > than actual code. The whole thing seems messy and hard to manage for all
> > but the smallest scripts.
>
> > Worst of all, sometimes the messages I wish to print may be expensive to
> > compute, and I don't want to waste time computing them if they aren't
> > going to be printed because the verbosity is too low. But nor do I wish
> > to fill my code with this:
>
> > if _verbosity >= 3:
> >     x = calculate_complicated_thing()
> >     print_(x, level=3)
>
> > Is there a better way of doing this than the way I am going about it?
>
> > --
> > Steven
>
> You can save some code if you use function decorators for logging
> input and output values of
> functions.
> So write lots of functions containing one statement and your problem
> is solved ;-)
>
> Greetings, Uwe

That would be perfect if python is a fully functional language (read
that as: purely functional language). Functional language dictates no
side effects, so logging input and output of functions is pretty much
everything needed to do debugging (which is the main reason for having
verbose mode). It would still be feasible, though, if you keep
yourself from using functions with side-effects (or use as few of them
as possible).

Bjorn Lindqvist says:
> One big downside with that approach is that it becomes much harder to
> grep for the log message. Usually when I go through logs, I don't care
> what exactly the message says, just that it is easily googleable (uses
> some kind of identifying text) and that it is unique so I can know
> exactly where it was emitted.

Actually, I'd prefer a log code (perhaps also as an option, to use -e
for showing up log code besides the log message). The log code would
be unique and referenced only once in the whole application (to nail
down who said what to a single point). The code would make a call to
the log printer with the log code (not the error string) and a few
arguments to be interpolated to the error string (taken from a
dictionary indexed by error code).

The downside is loss of inline documentation by the logging codes.