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 property() """ 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 ?-) -- http://mail.python.org/mailman/listinfo/python-list
