We might need to reevaluate our definitions of “concrete” and “abstract” API, as we’re turning more and more concrete APIs into abstract ones over time.
I’m not necessarily saying that’s a bad thing, but I do think it should be a deliberate thing.
I am personally +1 on this. It’s weird that for floats it would call the dunder but the only complex number type it understands is PyComplexObject. I don’t know if it would break anything though, maybe we can try how the fix affects e.g. the numpy test suite? (If numpy doesn’t build with the main branch, a hack to test this might be to apply the patch to the 3.12 branch, just to see if anything breaks.)
Maybe if some code rely on a weird behaviour of PyComplex_ImagAsDouble() (silently return 0.0 on anything non-complex). New code accept more input.
It seems numpy uses this either in case of PyComplex_Type subclasses or when the argument has could be casted to PyFloat_Type with PyFloat_AsDouble(). That shouldn’t be broken.
BTW the numpy test suite locally - pass. (I run one on patched CPython 3.12.)
Maybe I miss some example (here is a quick search over Github), but it seems other consumers of this API (including the CPython itself) do same: i.e. check if the object is a PyComplex_Type (or subclass of) and then run some function.
Then I think there’s no objection to this PR from the “C API WG”. It definitely is weird that the current contract is “argument must be a PyComplexObject* or anything supporting __float__.” It makes more sense for it to be “argument must support __complex__ or __float__.”