New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect description of descriptor invocation in Python Language Reference #67506
Comments
The section titled "Invoking Descriptors" in the Python Language Reference 1
This suggests that __get__ is looked up on the instance of x, when I believe
Here's some Python 3.4 code demonstrating this: class A:
pass
class Descriptor:
def __get__(self, obj, cls):
print("Getting!")
A.x = Descriptor()
def replacement_get(obj, cls):
print("This is a replacement.")
A.__dict__['x'].__get__ = replacement_get Now, writing: >>> A.x
Getting!
>>> A.__dict__['x'].__get__(None, A)
This is a replacement!
>>> type(A.__dict__['x']).__get__(A.__dict__['x'], None, A)
Getting! The documentation makes a similar statement about instance binding that also What I believe to be the actual behavior is implied by a later section in the |
I believe that you are correct: special methods are looked up on the type, and this is assumed implicitly in the Class Binding description. (This was not 100% true in python2, but it is in current python3.) 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). This is one of the most complex topics to describe in Python (I still don't have it solid in my head and I've been working with Python for years now). If we can come up with clearer wording that is good, but we've tried several times already to improve it :( I don't know what you are referring to for the 'instance binding' that makes the same 'mistake', but I suspect it is also covered by the "special methods are looked up on the type" rule. |
Ah, I see how writing a description of this which is both concise and precise
I see, but couldn't this also be held against the current "equivalent"? That I think I see now why this is difficult to document cleanly, and the "Special So saying x == y is equivalent to x.__eq__(y) isn't really correct, and saying |
See also bpo-20751. |
I think we can leave this as-is. It does a reasonable job of communicating where the descriptor is found and the arguments used when it is called. Marking this as out of date because later in the howto guide there is a precise pure python equivalent for the lookup and invocation steps. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: