Justin Eldridge added the comment: 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? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23317> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
