Message234763
Ah, I see how writing a description of this which is both concise and precise
would be difficult, especially for Python 2.
> But the Class Binding description is correct, since if the __get__ method is
> *not* defined on the type (of the descriptor), the descriptor instance itself
> is returned (so explicitly calling type in the "equivalent expression" would be
> wrong)
I see, but couldn't this also be held against the current "equivalent"? That
is, saying A.x is equivalent to A.__dict__['x'].__get__(None, A) is not stricly
true when __get__ isn't defined on type(x).
I think I see now why this is difficult to document cleanly, and the "Special
method lookup" section of the documentation does a good job of explaining this.
The issue isn't exclusive to descriptors. It affects, for example, the
documentation on rich comparison operators, which says that x == y invokes
x.__eq__(y), when this hasn't quite been true since old-style classes.
So saying x == y is equivalent to x.__eq__(y) isn't really correct, and saying
that it is equivalent to type(x).__eq__(x,y) isn't quite right either, as
implicit invocation may bypass the metaclass's __getattribute__. The latter,
however, seems "less wrong". Is there a reason that the former is preferred by
the documentation? |
|
Date |
User |
Action |
Args |
2015-01-26 17:54:08 | Justin.Eldridge | set | recipients:
+ Justin.Eldridge, r.david.murray, docs@python |
2015-01-26 17:54:08 | Justin.Eldridge | set | messageid: <1422294848.47.0.208362125773.issue23317@psf.upfronthosting.co.za> |
2015-01-26 17:54:08 | Justin.Eldridge | link | issue23317 messages |
2015-01-26 17:54:07 | Justin.Eldridge | create | |
|