On 20.10.2010 00:36, Seebs wrote:
On 2010-10-19, Martin P. Hellwig<martin.hell...@dcuktec.org> wrote:
Well, as with all styles IMHO, if there is a _good_ reason to break it,
then by all means do, but you might want to consider putting in a
comment why you did that and add the #pylint: disable-msg=<message_id>
on that line. If that is overkill, why not just comply to the standard
and avoid all the fuzz?
Well, part of what I'm trying to understand is why the standard in question
says what it says. I'm pretty much mystified by a claim that something with
seven instance attributes is "too complicated". For instance, I've got a
class which represents (approximately) a C function, for use in writing
various wrappers related to it. It has name, return type, args, default
values, a list of arguments which need various modifications, a default
return value, and so on... And it ends up with, apparently, 10 instance
attributes.
I can't tell whether there's actually a general consensus that classes
should never be nearly that complicated, or whether pylint is being a little
dogmatic here -- I haven't seen enough other Python to be sure. I'm
used to having objects with anywhere from two or three to a dozen or more
attributes, depending on what kind of thing they model. It seems like a
very odd measure of complexity; is it really that unusual for objects to have
more than seven meaningful attributes?
-s
The general idea is, that modules, classes, methods, and functions
should be small so they are better reusable, manageable and
understandable. If you have a huge class or function with many
attributes or local variables, it's often a sign, that your
class/function does to much and you better refactor this into
smaller pieces. There isn't and there can't be a general consensus
about /how/ small some part should be.
If pylint complains about too many variables or such, take it as a
hint to rethink your design. If you say, my design is good, then
feel free to ignore the warning.
If your classes wrap some existing datastructure and pyling
complains, take it as a hint (just a hint, not more) that maybe your
underlying datastructure is to complex.
But there are no general rules. In the end you (the programmer) has
to decide how the code or the data is structured, pylint can only
give you hints, that there *may* be a problem.
I don't know why "the standard" (what standard?) says what it says,
but I guess, it's the result of long time experiences and analysis
of existing code. Trust them, unless you are sure to know better.
--
http://mail.python.org/mailman/listinfo/python-list
