Automatic Generation of Python Class Files

Steven Bethard steven.bethard at
Tue Oct 23 19:30:20 CEST 2007

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 

> 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:

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.


More information about the Python-list mailing list