Automatic Generation of Python Class Files

[Bruno Desthuilliers]

Steven Bethard a écrit :
> Bruno Desthuilliers wrote:
> 
>> Steven Bethard a écrit :
>>
>>> Bruno Desthuilliers wrote:
>>>
>>>> Steven Bethard a écrit :
>>>> (snip)
>>>>
>>>>> In Python, you can use property() to make method calls look like 
>>>>> attribute access.  This could be necessary if you have an existing 
>>>>> API that used public attributes, but changes to your code require 
>>>>> those attributes to do additional calculations now.
>>>>>
>>>>> But if you're creating a class for the first time, it should 
>>>>> *never* use property().  There's no need to retrofit anything.
>>>>
>>>>
>>>> May I kindly disagree here ?-)
>>>
>>>
>>> Of course. ;-)
>>>
>>>> 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.
>>
>>
>> I once wrote a small ORM-like wrapper for LDAP access, and, for 
>> reasons that might be obvious for anyone having worked with LDAP, I 
>> choosed to keep the record values in the format used by the lower 
>> level LDAP lib and let user code access them thru computed attributes 
>> (actually custom-made descriptors).
> 
> 
> But this is trying to match an existing API,

Certainly not. There's *no* existing API here. It's just exposing as 
attributes some values that are *not* attributes, and that requires some 
computation to get at.

> the only case that I think 
> you *should* be using property().
> 
>> I could also list the CS101 examples, like Shape.area, 
>> Rect.bottom_right, Person.age, etc... And yes, some of these 
>> attributes are obviously read-only. That doesn't prevent them from 
>> being semantically *properties*, not *behaviour*.
> 
> 
> But as I mentioned in another email here, I'd rather know which ones 
> require computation, on the off chance that even the small amount of 
> additional calculation matters (say, for large integers or in a very 
> tight loop).

And then ? If you need to get this value, and getting it requires 
computation, then you'll have to do that computation - whatever the 
context. Looks like premature optimization to me. And then, what then if 
the implementation changes and what was plain attributes get turned into 
properties and vice-versa ?

> 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' !-)