pylint -- should I just ignore it sometimes?

Seebs usenet-nospam at
Fri Oct 22 18:13:18 CEST 2010

On 2010-10-22, Jean-Michel Pichavant <jeanmichel at> wrote:
> Seebs wrote:
>> 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.

> 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"


> 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

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.

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

Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam at <-- lawsuits, religion, and funny pictures <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

More information about the Python-list mailing list