pylint woes

[Chris Angelico]

On Sun, May 8, 2016 at 10:50 PM, D'Arcy J.M. Cain
<darcy at vybenetworks.com> wrote:
> On Sun, 8 May 2016 14:21:49 +1000
> Chris Angelico <rosuav at gmail.com> wrote:
>> if verbose:
>>     verbiage = print
>> else:
>>     def verbiage(*args): pass
>
> I have never understood why the def couldn't start on the same line as
> the else:
>
> if verbose: verbiage = print
> else: def verbiage(*args): pass
>
> The colon effectively starts a block so why not allow it?

Having two colons makes it a bit messy, so I can fully accept that
this *shouldn't* be done. Whether or not it's reasonable that it
*can't* be done is a question for the parser; but even if the parser
permitted it, I would expect style guides to advise against it.

> By the way, I think you meant "def verbiage(*args, **kws): pass"

In the general case, yes. But in this specific case, I actually prefer
not to accept keyword args in a null function; maybe permit sep=" "
and end="\n", but if someone sets file or flush, it's probably a
mistake (you most likely don't want verbiage("message", file=logfile)
to silently not do it). YMMV; maybe you want that, so yeah, toss in
the kwargs absorber.

>> Then, instead of "if verbose: print(var)", you would use
>> "verbiage(var)". Of course, you want something better than "verbiage"
>> as your name; the nature of your verbose output might give a clue as
>> to what name would work.
>
> How about "print"?
>
> if not verbose:
>     def print(*args, **kws): pass

The danger of that is that it's too general. I like to recommend a
little thing called "IIDPIO debugging" - If In Doubt, Print It Out.
That means: If you have no idea what a piece of code is doing, slap in
a print() call somewhere. It'll tell you that (a) the code is actually
being executed, and (b) whatever info you put between the parens
(ideally, some key variable or parameter). Part A is often the
important bit :) The trouble with a verbose flag controlling all
print() calls is that IIDPIO debugging suddenly doesn't work; plus,
it's easy to copy and paste code to some other module and not notice
that you don't have a verbosity check at the top, and then wonder why
disabling verbose doesn't fully work. Both problems are solved by
having a dedicated spam function, which will simply error out if you
didn't set it up properly.

But again, if you know what you're doing, go for it! This is exactly
why print became a function in Py3 - so that you *can* override it.

ChrisA