Author Justin.Eldridge
Recipients Justin.Eldridge, docs@python, r.david.murray
Date 2015-01-26.17:54:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1422294848.47.0.208362125773.issue23317@psf.upfronthosting.co.za>
In-reply-to
Content
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?
History
Date User Action Args
2015-01-26 17:54:08Justin.Eldridgesetrecipients: + Justin.Eldridge, r.david.murray, docs@python
2015-01-26 17:54:08Justin.Eldridgesetmessageid: <1422294848.47.0.208362125773.issue23317@psf.upfronthosting.co.za>
2015-01-26 17:54:08Justin.Eldridgelinkissue23317 messages
2015-01-26 17:54:07Justin.Eldridgecreate