Seebs wrote:
On 2010-10-19, Martin P. Hellwig <martin.hell...@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
--
http://mail.python.org/mailman/listinfo/python-list
