As Alan and I disagree on this, to a degree, I thought I would follow up to add
another perspective. Remember that it is _only_ perspective; Alan's opinions
are sound and have good reasons. So are mine:-) We place different values on
the costs and benefits here.
On 17May2015 00:27, alan.ga...@btinternet.com <alan.ga...@btinternet.com> wrote:
On 16/05/15 20:25, daaku gee wrote:
I think I understand what's going on here. What I don't understand is
if/when to use property instead of a normal attribute.
1. Is 'property' used widely? Do you use it?
No,
Yes, occasionally
For me: somewhat, and yes.
[...snip...]
2. Would you use it only when you need to validate or calculate the value
to be assigned to an attribute or is there any other place for 'property()'
to be used?
Those are the main use cases for me.
Calculating values can be an important one though,
especially if it avoids the need for lots of methods
to update some attribute like size. You can calculate
it at runtime and expose the method to look like a
data item.
But that in itself can be done by a method,
the real driver to a property is when I'm using the
class in a polymorphic relationship with other classes
that do have a data attribute and I want mixed access
with a common interface.
Here we differ, at least in where we draw the line. I am very fond of the
"property to calculate a value". It makes for more readable code:
foo.volume() + bah.volume()
versus
foo.volume + bah.volume
with less syntactic noise.
The "foo" and "bah" objects here might compute their volume from their more
basic attributes, perhaps length, height etc.
For Alan, using a property here provides no fundamental advantage over a method
call, especially since a property _is_ a method call underneath. He feels that
it breaks the OO model and as he mentions above, makes polymorphic use harder
because different types of objects might readily provide a .volume() method but
not a property.
For me, when the property such as .volume is (a) a basic thing trivially and
_repeatably_ computed from the other attributes and (b) cheap (usually O(1) to
compute, not requiring complex and expensive operations) and (c) having no side
effects such as creating files etc then I may often choose to use a property.
To me, the method/property distinction is in how the value it thought of:
A "computed", potentially complex or changing thing. This is a method.
A "direct" and simple thing, almost free to compute and (usually) stable. This
may be a property.
If you need to pass parameters other than "self", obviously it must be a
method.
3. If there is value in learning and using property, kindly explain it or
point me to a document/writeup/book that I should read to get a better
understanding.
Oddly enough I'm currently reviewing a book that addresses
this quite well in a chapter on properties. But it won't
be published till later in the year so not much help to
you just now.
Personally I wouldn't worry about them until you think you've
found a real use for them. There are plenty other things to
be doing first!
I'm in agreement here.
Become comfortable with methods and using them. Until that is second nature you
won't have much feel for when you may choose to use a property.
Cheers,
Cameron Simpson <c...@zip.com.au>
Heavier-than-air flying machines are impossible.
--Lord Kelvin, president, Royal Society, 1895.
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
