Automatic Generation of Python Class Files

Bruno Desthuilliers bdesth.quelquechose at
Wed Oct 24 00:07:03 CEST 2007

Steven Bethard a écrit :
> Bruno Desthuilliers wrote:
>>> I guess as long as your documentation is clear about which attributes 
>>> require computation and which don't...
>> Why should it ? FWIW, I mentionned that I would obviously not use 
>> properties for values requiring heavy, non cachable computation. This 
>> set aside, the fact that the attribute is computed (or not) is none of 
>> the concerns of client code. I think you know that concept, it's 
>> called 'encapsulation' !-)
> Encapsulation doesn't mean having no understanding of the object you're 
> using. 

Nope (or not exactly !-) but it means that interface should be decoupled 
from implemantation, and that, as a user, you shouldn't have have to 
worry that much about implementation details.

> We all use Python lists, knowing that adding to the end is 
> cheap, and adding to the front is expensive.  If you're using someone's 
> data type, but you have no idea where the performance costs are, you're 
> just asking for trouble.

Indeed. But
1/ this is true weither you use properties only for refactoring plain 
attributes or you use them righ from the start
2/ I'm sorry to have to repeat it, but I never advised using computed 
attributes for heavy computations.

>  That's true even if you're not prematurely 
> optimizing -- in the case of lists, doing the wrong sort of insert can 
> make an O(N) algorithm an O(N**2) algorithm. So I don't think this has 
> anything to do with encapsulation.

I can only agree on this. But is this really what we're talking about ? 
I thought you said - well, let me quote it, it will be simpler (nb: 
emphasis is yours):
if you're creating a class for the first time, it should *never* use 

Now you're talking about not _abusing_ this feature - a point on which, 
FWIW, I wholefully agree from the start. Are you saying that using 
properties is an abuse in itself ?

If then, one should only use explicit accessors ? But then, what would 
prevent anyone to put heavy computations into accessors ?

And else - ie, if you think using computed attributes is legitimate for 
simple things - why not using them right from the start when it makes 
sens instead of having a strange mix of attribute syntax and explicit 
accessors syntax (for an implementation that may finally end up using 
properties under the hood and have explicit accessors just, well, 
accessing a plain attribute) ?

> This really only has to do with what you and I think are natural 
> programming intuitions. I agree that Python is not Java, or C, or 
> whatever, but there are a wide variety of precedents in a wide variety 
> of languages (the Python stdlib included) that lead many programmers to 
> expect only minimal computation to be performed when accessing 
> attributes.

Should I mention *once again* that I never advertized using properties 
for heavy computations ?-)

> I believe we simply disagree on whether or not Python 
> programmers need to be trained out of these expectations.

I believe we simply disagree on weither properties should be used when 
it makes sens (from a semantic POV, which doesn't prevent common sens, 
thanks) or if they should be restricted to refactoring-life-saver. Now 
since the second use implies that some attributes-looking properties of 
an object may not be what they looks like - and even worth, may suddenly 
become (a little bit) more costly without client code being warned - I 
don't see what's your problem with the first one.

Ok, I think we all understood your (quite sensible) concerns about not 
calling super-heavy-computations without knowing, but (did I say it ?) 
that's certainly not what I'm talking about, nor how anyone in it's own 
mind would use this feature. No, don't tell me, I know there are a 
couple ho-so-very-smart peoples out there that actually will. But what ? 
There's no cure for stupidity. So far, it seems that most Python users 
don't suffer from such major brain disorders - I'd even find them 
suprisingly reasonnable when it comes to black magic -, so I don't think 
there's a need for such a rule as the one you were suggesting.

Ho, and wrt/ training and expectations, I'm afraid you have to live with 
the fact that computed attributes (either properties and custom 
descriptors) are alreay widely used. FWIW, may I remind you that a 
method is actually a callable returned by a computed attribute ?-)

More information about the Python-list mailing list