[Python-Dev] Computed-attributes

[Paul Prescod]

Gordon McMillan wrote:
> 
> What happens here (and when):
> class A:
>   y = None
> class B(A):
>   def __XXX_y__(self):
>      ...

I would say that the latter would just take precedence over the former
as if you had typed:

class B(A):
    __XXX_y__=ComputedAttribute( foo, bar, baz )
 
> Hmmm. Current Python: search for y fails, try __getattr__.
> Proposed: search for y fails, try the __get_y__, then
> __getattr__. We've still done the same work before trying the
> hook, so how is performance affected? 

Actually, I was justifying Python's current behavior as much as I was
the current behavior. A truly general __getattr__ would access all
attribute tests, not just non-existent attributes and thus be symmetric
with setattr. But that would also be slow as hell.

> class A:
>   def __get_y__(self):
>     ...
> class B(A):
>   def __set_y__(self, value):
>     ....

My first instinct is just to disallow this and figure it out after we
have some more usage information/implementation resources. We could just
say that all methods must be defined in the same class and if not. In
other words, the methods "shadow each other" as a group.

This is no more messy than inherited __getattr__ s.

My second thought is to have the constructor for computed attributes
objects look for a computed attribute higher in the tree and copy in the
appropriate fields.

Prohibiting it might be clearest for all concerned.

-- 
 Paul Prescod - Not encumbered by corporate consensus
"Hardly anything more unwelcome can befall a scientific writer than 
having the foundations of his edifice shaken after the work is 
finished.  I have been placed in this position by a letter from 
Mr. Bertrand Russell..." 
 - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox)