pylint -- should I just ignore it sometimes?

[Alexander Kapps]

On 19.10.2010 21:57, Seebs wrote:
> So, I'm messing around with pylint.  Quite a lot of what it says
> is quite reasonable, makes sense to me, and all that.
>
> There's a few exceptions.
>
> One:  I am a big, big, fan of idiomatic short names where appropriate.
> For instance:
> 	catch<something>, e:
> I don't want a long, verbose, name -- "e" is about as much in need of
> a long and descriptive name as the stereotypical "i" one would use as
> a loop index (in a language without iterators).  Should I just ignore
> that, or is it really more Pythonic to say something like:
> 	catch KeyError, exception_resulting_from_the_use_of_a_key_not_defined_for_the_dictionary_in_which_it_was_looked_up:

catch KeyError, exc
catch KeyError, exception

> Secondly:  I am getting a couple of hits on things like "Too many instance
> attributes (8/7) or "Too many branches (14/12)".  In the cases in question,
> it doesn't seem to me that the number of instance attributes is particularly
> devastatingly complicated, because the instances in question are, by design,
> sort of data stores; they carry a handful of precomputed results that are
> then reused to populate templates.
>
> So am I going to be laughed out of the room if I just let a class have
> eight instance attributes, or use a short name for a caught exception?
>
> -s

Pylint gives *hints* about *possible* problems or bad style. I 
personally think it's good practice to take care of all of them and 
carefully think if you or pylint is right. Once you decided that you 
are right, you can configure pylint to not complain about certain 
aspects. See man pylint for more.