On 24Jan2015 00:47, Alan Gauld <alan.ga...@btinternet.com> wrote:
On 24/01/15 00:37, Cameron Simpson wrote:
By contrast, I use it a far bit (though still far less than non-property
methods). Generally for derived properties which are:
- cheap to compute i.e. O(1)
- which I want to abstract
- usually represent some property which is stable, such as a size
- occasionally (much more rarely) a property which is not stable,
But why a property rather than a simple method?
Why is
k = url.key
better than
k = url.key()
for meeting those criteria?
Because it is a value that feels like an attribute.
A method that always returns the same value for a given object (and is very
cheap) is, to my mind, not worth burdening the caller with the detail that is
it a function.
If the caller can ask for o.key() and be given a value that is stable, and will
not change (and therefore will never require another call if the caller bothers
keeping the value around) then why should the caller care that it is a
function? So why should it even look like a function?
It should look and feel like any other object attribute - a simple value that
can just be examined.
My intuition is that a function is costly (potentially) and that consulting an
attribute is very cheap. I don't want to break such intuition.
Consider .keys() for a dynamic mapping. Changeable, and expensive. It should
look like a function.
Cheers,
Cameron Simpson <c...@zip.com.au>
A pessimist is an optimist in full possession of the facts.
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
