[Python-Dev] PEP 208 comment

[Martin v. Loewis]

> 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