On 18 juin, 15:05, Ethan Jucovy <ethan.juc...@gmail.com> wrote:
> I tend to avoid @property -- it adds conceptual overhead for code
> readers (hiding the fact that a function call is taking place) for little
> gain.
Would you say that the way the attribute lookup mechanism and
descriptor protocol are used to turn function class attributes into
methods "adds conceptual overhead for little gain" and that it would
be better to have to explicitely lookup the function on the class and
explicitely pass the instance, ie write:
type(obj).method(obj, arg)
instead of
obj.method(arg)
?
> Beyond that, my preferred rule of thumb is that I will not use @property if
> any non-trivial computation takes place.
That's a POV. I personnaly tend to use properties (or custom
descriptors) for anything that has the semantics of an attribute and
is either trivial to compute or trivial to memoize.
> But I try to avoid it even for
> trivial computations. Methods are more self-documenting and more flexible
> (e.g. less refactoring needed if you end up adding function arguments later)
If you ever have to "end up adding arguments later", then it wasn't
really an attribute and should have been a method right from the
start. Design mistake - and yes, it happens, I don't mean I'm smarter
than you ;)
But even then, since adding extra params means you'll have to fix
client code, the "less refactoring" argument doesn't stand IMHO.
All this being said, I wholefully agree that while computed attributes
are very handy, one should not go over the top and use them for no
good reason - simple code is hard enough to maintain.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
