> Wrong name. The TPFLAGs only indicate whether a struct is large enough to
> contain a particular member, not whether that member is going to contain or
> do anything.
That may have been the original intention; *this* specific flag is not
of that kind. Please look at abstract.c:binary_op1, which has
if (v->ob_type->tp_as_number != NULL && NEW_STYLE_NUMBER(v)) {
slot = NB_BINOP(v->ob_type->tp_as_number, op_slot);
if (*slot) {
x = (*slot)(v, w);
if (x != Py_NotImplemented) {
return x;
}
Py_DECREF(x); /* can't do it */
}
if (v->ob_type == w->ob_type) {
goto binop_error;
}
}
Here, no additional member was added: there always was tp_as_number,
and that also supported all possible op_slot values. What is new here
is that the slot may be called even if v and w have different types;
that was not allowed before the PEP 208 changes. Yet it tests for
NEW_STYLE_NUMBER(v), which is
PyType_HasFeature((o)->ob_type, Py_TPFLAGS_NEWSTYLENUMBER)
So the presence of this flag is indeed an promise that a specific
member will do something that it normally wouldn't do.
> 'Py_TPFLAGS_HASCOERCE' or some such would seem more appropriate to
> me.
Well, all numbers still have coercion - it just may not be used if the
flag is present. It's not a matter of having or not having something
(well, only the "new style" numbers may have nb_cmp, but calling it
Py_TPFLAGS_HAS_NB_CMP would be besides the point, IMO).
Anyway, I don't want to defend my version too much - I just want to
request that the current name is changed to *something* more
descriptive.
Regards,
Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4