[Tutor] Python property()

[Cameron Simpson]

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.gauld at btinternet.com <alan.gauld at 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 <cs at zip.com.au>

Heavier-than-air flying machines are impossible.
      --Lord Kelvin, president, Royal Society, 1895.