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.
-- http://mail.python.org/mailman/listinfo/python-list
