BUG: Fix complex+longdouble and broken subclass handling

When we see a complex number, we should go into the "promotion" path
even for longdouble.  That is because the complex number will behave
the same as a NumPy complex scalar and thus promotion works fine
(no issue with potential infinite recursion that would happen if we
go into the object loop).
Further, with a slight slowdown (but not slower than before), we now
check for subclasses of int, float, complex always and while we do
check whether we should defer, coercion is considered valid.

That is: We do not explicitly defer to a subclass of float unless e.g.
`__array_ufunc__ = None` or `__array_priority__` is set.

Some (arguably broken) subclasses may for exampleonly add an `__rop__`,
but not an `__op__`.  For these, the previous `is_forward` logic did not
work out correctly and could go into the wrong branch.
This is now fixed, by first checking for exact maches, and then also
checking for subclass, it should be safe to assume that one operand
is a subclass, but that is the only thing we can assume.

I now think that the only way to possibly get subclassing right, would
be by defining `__op__` and `__rop__` on a class to ensure that the
subclass cannot possibly inherit the base version.
(To be clear, I do not think that is worthwhile, and Python does not
do it either.)

0 files changed, 0 insertions, 0 deletions