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
Inhomogeneous behaviour for descriptors in between the class-instance and metaclass-class pairs #83624
Comments
Assume one has defined the following descriptor:
On the one hand, for the class-instance pair, the behaviour is as follows:
results in "SET" being displayed twice; i.e. both assignations triggered the __set__ method of the descriptor. On the other hand, for the metaclass-class pair, the behaviour is the following:
results in "SET" being displayed only once: the first assignation (the one in the class definition) did not triggered __set__. It looks to me like an undesirable asymmetry between the descriptors behaviour when in classes vs when in metaclasses. Is that intended? If it is, I think it should be highlighted in the descriptors documentation. Best |
First of all, thanks for asking about this. Everything is working as expected. Let's look at why. First, be sure the behavior of descriptors is clear: the descriptor protocol is only triggered by "dotted access" on an object ("obj.attr"). So you should expect it only where you see that syntax used. Let's look at your examples now.
In this case there are 2 dotted accesses. The first one happens in __init__() when the object is created. The second is the rest of the above line.
In this case there is only one dotted access, in that last line. The object in this case is SecondClass and its class is SecondClassMeta. Unlike with FirstClass, the *class* in the second example (SecondClassMeta) does not have a __init__() with the dotted access. Instead there is only the one dotted access afterward. If SecondClassMeta had the same __init__() that FirstClass had then you would have seen a second trigger of the descriptor. It seems you expected assignments (name binding) in the class definition body to be treated the same as dotted access. They are not. This is because when a class definition body is evaluated, the class object does not exist yet. The steps for class creation go like this:
Python has worked this way since version 2.2 (PEP-252). See: https://docs.python.org/3/reference/datamodel.html#creating-the-class-object If you want to get clever you could return a namespace object from your metaclass __prepare__ that triggers the descriptor protocol as you expected. However, I would not recommend that. Getting clever with metaclasses is best avoided. The default behavior is much simpler. That won't be changing.
Regardless, metaclasses are used infrequently and combining them with descriptors (especially relative to class definitions) is even less common. So pointing out the caveats of this case may not be worth the time of all future readers of those docs. That said, clearly it would have helped you in this case. :) So here are some *possible* places to clarify (very briefly):
Which of those do you think would have helped you the most? |
@Raymond, What do you think about adding a helpful note or two in the docs? |
Thanks for this detailed answer; very instructive :)
Indeed; this is what I was missing... despite it is indirectly mentioned in the documentation. Nonetheless, it could be worth the overload to explicitly add in the language reference that 'the descriptor protocol is only triggered by "dotted access"' (looks like it is not the case for now).
Could be really helpful as well, by clearly exhibiting the limitations of the descriptors; I think the best location for this could be the 'descriptors howto' page despite the other option is perfectly suitable as well. Best, |
Some thoughts:
|
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: