Marc 'BlackJack' Rintsch wrote:
> On Mon, 22 Oct 2007 17:31:51 -0600, Steven Bethard wrote:
>
>> Bruno Desthuilliers wrote:
>>> Computed attributes are IMHO not only a life-saver when it comes to
>>> refactoring. There are cases where you *really* have - by 'design' I'd
>>> say - the semantic of a property, but know from the start you'll need
>>> computation (for whatever reason). Then what would be the rationale for
>>> using explicit getters/setters ?
>> I'd be interested to hear what these use cases are.
>
> Stupid little example: A circle object with `radius` and `diameter`
> attributes. It doesn't make sense to store both a as normal attributes
> because they will eventually get out of sync. One can be implemented as a
> property.
Could be. But I'd tend to define a get_diameter() method here. As a
user of your class, I'd like to know which one is doing the computation.
What if I'm using ridiculously large ints, and I care about the
multiplication?
> Another one is delegation of attribute access. I'm thinking of a wrapper
> class around an object with an attribute, say `is_active`, and a wrapper
> that has a property with the same name that returns the value of the
> wrapped objects attribute.
This is retrofitting to an API, so it already falls under the only time
I think you *should* be using property(). Although in this case, it
might be that __getattr__ is more appropriate.
> Or lazy computation of an attribute. Breaks expectations for the first
> access -- long calculation for simple attribute access -- but meets it for
> every subsequent access.
There are descriptors better than property() at achieving this behavior.
See for example:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/363602
My personal experience is that every time I write stuff this way (and I
have many times), I end up re-writing it later as a method because it's
less confusing for a method to take a long time than it is for an
attribute access.
STeVe
--
http://mail.python.org/mailman/listinfo/python-list
