pylint -- should I just ignore it sometimes?

[Jean-Michel Pichavant]

Seebs wrote:
> On 2010-10-19, Martin P. Hellwig <martin.hellwig at dcuktec.org> wrote:
>   
>> Speaking without context here, so take it with as much salt as required 
>> ;-), it is not that unusual. However there are some things to consider, 
>> for example are all these attributes related to each other? If so 
>> wouldn't it be more pythonic to have one attribute which is a dictionary 
>> and store your stuff in there?
>>     
>
> I don't know.  Does "pythonic" mean "needlessly verbose"?  :)
>
> I did, in an early draft, have something that basically came down to:
>
> 	self.foo = {}
> 	self.foo['a'] = a()
> 	self.foo['b'] = b()
>
> and then I realized that I could just write:
> 	self.a = a()
> 	self.b = b()
>
> and spend a lot less extra typing on repeating something that, by virtue
> of being repeated constantly, was therefore meaningless.  It wasn't creating
> a meaningful distinction, it wasn't showing a meaningful relationship...
> All these things are attributes of the thing itself, not attributes of its
> dictionary.
>   

Difficult to argue about meaning when you give a meaningless example :)
The question you have to answer is : "Is a and b attributes of self 
(whatever that is)".

Actually everything should be driven by its meaning, not if it's quicker 
to write or something like that.

Regarding the first question about ignoring pylint:
It's a tool, and requires a lot of configuration.
1/ define *your* coding rules (PEP 8 is just one coding rule among the 
others, it's only required if you want to commit into the standard library)
2/ When you know about your rules then configure pylint so it suits with 
those rules.
3/ Never ignore a defect reported by pylint. If a pylint rule does not 
satisfy you, disable it so pylint stops reporting it.



except ValueError, e:

Use meaningful names, this is so important. 'e' is not meaningful. 
'exception' would be slighly better. On that particular case, pylint is 
right to complain. When dealing with such issue like "I'm too lazy to 
write proper engligh" always think that what is the most important thing 
is to save the Reader's time, not the Writer's time. Using 'e' would 
force to reader to introspect to code to get an idea of what 'e' is. 
Moreover, code completion makes use of long names costless.

You should read this very good paper about naming:
http://tottinge.blogsome.com/meaningfulnames/

JM