Repository navigation
Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to) #70291
Description
Activity
aaronchall commented
on Jan 13, 2016 aaronchallmannequinMannequinAuthorBased on the data-model documentation (https://docs.python.org/2/reference/datamodel.html#invoking-descriptors) and the dotted lookup behavior, the follow definitions are correct:
"If the descriptor defines __set__() and/or __delete__(), it is a data descriptor; if it defines neither, it is a non-data descriptor."
def has_data_descriptor_attrs(obj): return set(['__set__', '__delete__']) & set(dir(obj)) def is_data_descriptor(obj): return bool(has_data_descriptor_attrs(obj))
However, the inspect module has the following, which is also reflected in the descriptor how-to (https://docs.python.org/2/howto/descriptor.html#descriptor-protocol):
"If an object defines both __get__() and __set__(), it is considered a data descriptor."
def isdatadescriptor(object): """Return true if the object is a data descriptor.
Data descriptors have both a __get__ and a __set__ attribute...""" if isclass(object) or ismethod(object) or isfunction(object): # mutual exclusion return False tp = type(object) return hasattr(tp, "__set__") and hasattr(tp, "__get__")I'm willing to sign a contributor release and fix myself.
aaronchall commented
on Jun 5, 2017 aaronchallmannequinMannequinAuthorBumping this - I intend to work on this next, if no objections.
This isn't just a documentation issue since it fixes inspect.isdatadescriptor(). I confirm that the new implementation better matches the C code. LGTM, but needed tests for inspect.isdatadescriptor() and a Misc/NEWS entry.
aaronchall commented
on Jun 6, 2017 aaronchallmannequinMannequinAuthorAdded news, working on tests
aaronchall commented
on Jun 6, 2017 aaronchallmannequinMannequinAuthorPlease also add yourself to Misc/ACKS.
Done!
aaronchall commented
on Jun 8, 2017 aaronchallmannequinMannequinAuthorI tweaked the docs a little more this morning, but I believe I am done making any further changes unless so requested.
This issue doesn't say it's assigned to anyone. Is there anything else that needs to happen here?
aaronchall commented
on Sep 4, 2017 aaronchallmannequinMannequinAuthorSerhiy,
Not sure what else needs to be done to wrap this up. All checks are passing on the pull request.
Thoughts?
The only question is remained -- should *data descriptors* be *descriptors*? I.e. is the __get__ method required for data descriptors?
chnlior commented
on Dec 11, 2017 chnliormannequinMannequinJoining @serhiy Storchaka last question.
Is the __get__ method existance is a must be a data descriptor?According to the C implementation in descrobject.h
#define PyDescr_IsData(d) (Py_TYPE(d)->tp_descr_set != NULL) #endifthe answer is No.
Does this C code reflect the true definition?It looks like this issue can be closed now that it's merged?
I suspect that this issue was resolved in the wrong direction. It is meaningless and not useful to define something as a "data descriptor" that does not have a
__get__method, since the only implication of something being a "data descriptor" is that its__get__method takes precedence over the instance dict. But obviously this "taking precedence" cannot occur when the descriptor has no__get__method. So I think it is more useful to clarify that data descriptors must have both__get__and either or both of__set__and__delete__.The reason
PyDescr_IsDatadoes not explicitly check fortp_descr_getis that, in every case where it's used, the accompanying step (either immediately before or after thePyDescr_IsDatacheck) is to actually fetchtp_descr_getfrom the descriptor; if it isNULL, then attribute-getting always proceeds exactly as if the descriptor were not a data descriptor. (In fact, in 3/4 call sites the check is literally(descr_get != NULL && PyDescr_IsData(descr).) So also checking existence oftp_descr_getwithinPyDescr_IsDatawould be redundant in every place it is used. But the end-to-end behavior in all these cases is that descriptors withouttp_descr_getbehave exactly the same as non-data descriptors. I don't think we wantPyDescr_IsDatato do the redundant check (these are hot code paths; though tbh compilers might be smart enough to eliminate it anyway), maybe it should be renamed for better clarity?I'm not sure whether this is important enough to file a new issue and fix. The main case where I can see it might cause confusion is that e.g. if
inspect.getattr_statichewed blindly to the currently-documented definition of what makes a data descriptor, it would wrongly return the descriptor object instead of the instance dict value for descriptors without__get__. (Fortunately it doesn't follow the documented definition, but also checks for__get__.) This came up in #75367.
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: