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)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4