For a bit of context the PR that @skirpichev mentions, python/cpython#119372, is a currently open PR against core Python that (if merged) will change the semantics of complex division for Python complex objects in these corner cases. NumPy (and in particular the NumPy test suite, if it tests for compatibility between complex and np.complex128) seems like the most likely 3rd party package to be broken by such a change, and I wanted to make sure that the NumPy developers were aware of the pending change and had an opportunity to push back if they deem the risk of breakage to be too high.

Some libraries may test against NumPy and copy us bug-for-bug, but those should just keep up.
NumPy tries to follow Python in many things, not sure I would say necessarily strictly for this kind of edge case (unlike divmod). Seems like this one is pretty clear cut an improvement if the C standard defines it (and I doubt performance matters either).
I believe we have actual a similar or even identical PR to fix reciprocal for this corner case.

In any case, long story short: I think you can change this and NumPy should also fix it in either case. Neither does it sound like a burning issue or an issue if NumPy "diverges".

Thanks, @seberg!

JFR:

• numpy already has a different behaviour (wrt Python) for division by zero:

  numpy/numpy/_core/src/npymath/npy_math_complex.c.src

  Lines 105 to 107 in 012e63d

  	if (abs_br == 0 && abs_bi == 0) {
  	/* divide by zeros should yield a complex inf or nan */
  	return npy_cpack@c@(ar/abs_br, ai/abs_bi);

• referenced numpy pr is, probably, that one: BUG: fix reciprocal of 0+0j to be inf+nanj #17449 It's outdated, but I doubt it's identical or even a similar. In fact, mentioned CPython PR doesn't touch that condition of the Smith's algorithm (python just raises a ZeroDivisionError here).

I'll work on a patch.