pylint -- should I just ignore it sometimes?

[Jean-Michel Pichavant]

Let me quote the paper I linked in the previous post:

list1 = []
for x in theList:
if x[0] == 4:
list1 += x;
return list1

compare it to:

flaggedCells = []
for cell in theBoard:
if cell[STATUS_VALUE] == FLAGGED:
flaggedCells += cell
return flaggedCells

The latter is better, but:

flagged = []
for cell in board:
if cell.flagged():
flagged += cell;

is probably even better.
[snip]
-s

Right, may be there is an even better solution. This is not the point.
The point of this example is to show the power of meaningful names in a
very basic example. You said it yourself, the latter is better.

JM

 

[Jean-Michel Pichavant]

In this case, yes.

The one that brought this up, though, was "except FooError, e:", and in
that case, there is no need for any further description; the description
is provided by the "except", and "e" is a perfectly reasonable, idiomatic,
pronoun for the caught exception.

-s

same for the exception.

Let's say you're reading some code, someone else code. You can't just
read everything so you're reading through quickly.

You first hit that line:

"print e"

You have *no* idea what e could be. It could be the number e... You can
now try to read through the above code and find out. And it's easy to do
that, Anyone can do that. But it takes time ! only 1 sec maybe but
that's still 1 sec, and when you are reveiewing code, it can be really
tedious.

Immagine now you hit
"print exception".
Then you know, he's trying to print an exception, do you need to care
about that ? If so introspect the code, try to know wich exception
class, but if the answer is 'I don't care about the exception being
printed' you can just continue and read the code like a book It saves
a lots of time.


Regarding another point you mentioned in this thread, your brain can
read "number" as fast as "num" so it doesn't take more time to read
proper english, than abreviations all around (I think it's the opposite
actually).

Your brain can instantly recognize a known face while it take a huge
amount of computation for a CPU to do so.
All I'm saying is that the brain is not reading a sequence of letters,
but recognize some known pattern as a whole, so reading time is not
related the word length.

JM

 

[Seebs]

list1 = []
for x in theList:
if x[0] == 4:
list1 += x;
return list1
flaggedCells = []
for cell in theBoard:
if cell[STATUS_VALUE] == FLAGGED:
flaggedCells += cell
return flaggedCells

The latter is better, but:

Right, may be there is an even better solution. This is not the point.
The point of this example is to show the power of meaningful names in a
very basic example. You said it yourself, the latter is better.

But it's a very contrived example, where bad style is held up for admiration
by comparison with atrocious style. That's not a persuasive argument!

In fact, the "better" example can be massively improved by *shortening*
it, lending weight to my general contention that verbosity for the sake
of feeling like we're making things clearer is not an effective way to
make things clearer.

-s

 

[Seebs]

same for the exception.

No, not the same.

Let's say you're reading some code, someone else code. You can't just
read everything so you're reading through quickly.

You first hit that line:

"print e"
Yup.

You have *no* idea what e could be. It could be the number e... You can
now try to read through the above code and find out. And it's easy to do
that, Anyone can do that. But it takes time ! only 1 sec maybe but
that's still 1 sec, and when you are reveiewing code, it can be really
tedious.

I don't think I ever first hit the first line of a block rather than the
control for the block.

Immagine now you hit
"print exception".
Then you know, he's trying to print an exception, do you need to care
about that ? If so introspect the code, try to know wich exception
class, but if the answer is 'I don't care about the exception being
printed' you can just continue and read the code like a book It saves
a lots of time.

Except it doesn't.

Because it takes enough longer to read that, and enough longer to read
the surrounding code, that it's taken me longer than it would have if the
name had been short.

Regarding another point you mentioned in this thread, your brain can
read "number" as fast as "num" so it doesn't take more time to read
proper english, than abreviations all around (I think it's the opposite
actually).

There certainly exist cases where a shorter thing is harder to read than
a longer thing, however, there are many cases where short names, especially
idiomatic ones, are much, much, faster. Individual letters are things
that most English speakers will pick up essentially instantly, making them
good candidates for variables.

There is a reason that mathematicians write dy/dx, rather than
"the rate of change of the vertical axis value divided by the rate
of change of the horizontal axis value." It's that people can, in fact,
read these things much faster.

Your brain can instantly recognize a known face

Strictly speaking, actually, no. But I grant that most peoples' can.

All I'm saying is that the brain is not reading a sequence of letters,
but recognize some known pattern as a whole, so reading time is not
related the word length.

Yes, and all you're saying is wrong. Reading time is strongly related to
word length overall. If you are looking entirely at known words, you
will absolutely read "he" a lot faster than you read
"antidisestablishmentarianism". Similarly, even people who are pretty
active in the field might have to slow down to tell homoiousia from
homoousia, while very few people will have a hard time telling x from
y. The more long words you embed, the more of the data you're presenting
the user with is irrelevant to what's happening.

For short to medium length words, there's not usually much advantage
from a shorter word, assuming that everything you're looking at is in
fact natural words, but you're more likely to overlook typos or miss
details.

Coupled with punctuation, layout, and the rest, short words can help
reduce the wall-of-text effect, which can massively hurt reading speed.

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.

-s

 

[Jean-Michel Pichavant]

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.

-s

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

[ 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 )

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

Cheers,

JM

 

[Seebs]

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 )

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

 

[Dennis Lee Bieber]

Let's say you're reading some code, someone else code. You can't just
read everything so you're reading through quickly.

You first hit that line:

"print e"

If I'm skimming down from the top of the program, I'd be looking for
/structure/... That is, the statements defining block boundaries -- and
not whatever computations are performed within the blocks; those are
only relevant once one has an idea of how one gets to that section...

So for the above my mental processes would be...

try:
some irrelevant computation
except something, e:
more insignificant stuff

after which, if the exception processing is of interest I'd have seen
that the exception data has been given the name "e", and would expect to
find "e" used somewhere within "more insignificant stuff".

 

[Dennis Lee Bieber]

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

I'd be using:

[str(d) for d in week]

"week" describes the object/concept being iterated over... Since the
logical breakdown of a week is days, I don't need to use "day" to know
what the individual items are...