pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-22, Jean-Michel Pichavant <jeanmichel at sequans.com> wrote:
>> I'm all for descriptive names, but there's a great deal of benefit to
>> knowing when a descriptive name will help, and when all you need is a
>> variable which will be quickly recognized.

>> Compare:
>> [theValueInTheList.func() forTheValueInTheList in theList]
>> [x.func() for x in list]

>> One of these is much, much, easier to read than the other.  It's
>> not the one that used a "descriptive" name.

> You did not use descriptive names in your example, but verbose names. 
> That makes a huge difference.

Well, they certainly describe the objects in question better.

> [ str(day) for day in week ]
> [ str(x) for x in _list]
> [ str(d) for d in w ]

> I let you decide which one is better. After that I'm running out of 
> arguments :o)

This is an interesting example!  I would probably use str(x) for x, because
the idiom of using "x" trumps the details of what we think x is in a
particular case, but I do like "week" better than "_list", certainly.

Unless, of course, we have context:

def strings(week):
    [ str(day) for day in week ];

In that case, I'd think that
    [ str(x) for x in list ]
would be much clearer.

In general, I don't like to use single-letter abbreviations unless they're
consistent as part of an idiom.  I'm fine with "s" for a string, "e" for
an exception, or "i" for an index.  I wouldn't normally use "d" for a day,
because that's not a convention.  (There's similarity to pronouns; pronouns
are great, but you can't usually just invent new ones.)

> Note that I did not suggest to write
> [ aDayInAWeek.displaymeCauseImAwesome() for aDayInAWeek in 
> weekContainingSomeDaysHopefully ]

Heh.

I think one thing that's been somewhat missed is the importance of
surrounding context.

I would have no problem with:

	except KeyError, e:
	    print "How on earth did we get a KeyError:", e
	    exit(1)

or something similar.  (Ignoring, for now, the issues with "exit(1)".

If we had a much larger and more complicated bit of processing, much
of which didn't use or refer to the exception, and then came back to it,
though, I might prefer a name which will be easier to track:

	except KeyError, e:
	    # time to get clever!
	    new = alternative_list()
	    new = [x.fixup() for x in new]
	    if new.size > 3:
		more_complicated()
		stuff_here()
	    else:
		and_now_a_little_song()
	    ...
	    ...
	    ...
	    else:
		print "I couldn't recover, sorry.", e

I'd find that much less attractive, because at that point, e is no longer
really working like a pronoun; it's not a common thread throughout the
execution, but a reference to context some distance previously, and it
hasn't been maintained.  So a big part of the question, for me, is how
regular and consistent the usage is.  I don't mind i for a loop index for
something that's heavily using i.  I don't mind it for something where
i is never used at all inside the loop, just as a counter.  But if there's
a large complicated bit of processing, with a single reference to "i"
buried in the middle of it, then I'm going to want to replace it with a
name that tells you what it is.

The tradeoff there is largely a question of what it's like to read the
code.  If reading the code makes the variable's usage obvious, a one-letter
name may be appropriate, especially if the variable's meaning is really
nothing more specific than "that thing we're working with".

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam at seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.