I don’t think it’s a good idea for this behaviour to change automatically with the Python version, but it seems nice to have the option.

Floating-point numbers have a concept of signed zero. The sign should be taken into account when this is used in the denominator. The meaning of 0.0 is really more like lim_{x->0+} x, and similarly for “negative zero”.

This seems like what NaN is for.

Unlike with real numbers, the “complex zero” doesn’t easily convey the angle at which 0 is approached. (0.0, -0.0, 0.0j, -0.0j are only four possibilities out of, as mathematicians reckon, uncountably many.) Consequently, dividing by it doesn’t give a clear result. Even if the angle is known, to specify the result properly, you’d need (positive) “infinity” paired with an angle, not the usual real-part + imaginary-part representation. (You can get some really weird behaviour if you try to mess around creating these kinds of values.) There is also in complex analysis the concept of “complex infinity” (complex value of infinite magnitude and unspecified angle), or the “line / circle at infinity” (the set of all values of infinite magnitude).

I probably still got some pedantic details wrong. The point I am trying to make is that complex numbers are… complex, and it would be better not to try to extend their functionality if there’s a chance of giving incorrect results.

My first thought is that I would expect a signed result. In integers, 0 is normally considered positive rather than negative. Here, it’s hard to draw inspiration from mathematics, because integers are not closed under division.

In fact, our lab returns different results, and these are all about the complex, or go to the inf.
I am still figuring out which result is the best, and in what situation.

This is a bug in the Python division. I will also investigate the problem.

When trap is enabled, All of these calculations will raise SIGFPE. The reason is explained in that page. I think Python should keep the behavior as is.

Not backwards compatible. Changing how division by zero behaves would break existing code.

Mathematically wrong. In general, a / 0 is not inf, from a mathematical point of view. a / 0 is undefined. lim(x->0) a / x == inf for certain values of a, but lim(x->0) a / x != a / 0.

Most importantly, IMO, inf is significantly less useful than ZeroDivisionError in most cases. If I’m working on a piece of code and accidentally introduce a zero-valued denominator, I want to know that. If division of zero instead just produced inf,

the inf may propagate further through the program, causing it to break in a hard-to-predict fashion somewhere else.

I wouldn’t immediately know what went wrong even if I did catch the inf where it first appeared, because division by zero is not the only operation that could produce inf.