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.