On Tue, Mar 10, 2020 at 11:16 PM Marco Sulla via Python-list <python-list@python.org> wrote: > Raising a NanError seems to me the only way to eliminate the NaN > problem. Indeed NaN was created for languages like C, that does not > support exceptions.
People keep saying this - that nan exists to avoid exceptions - but that doesn't take signalling nans into account. Even in C, they are expected to raise an exception or equivalent. Python raises an exception for float division by zero because Python does its best to treat smallish integers and integral floats as equivalent. (Yes, I'm using "smallish" to mean "less than nine quadrillion"... programmers have weird ideas about magnitude sometimes.) Apart from indexing, the values 3 and 3.0 should be able to be used pretty much interchangeably. They compare equal (which, in turn, implies that they have the same hash), they behave very similarly in arithmetic, etc, etc, etc. It makes good sense for division by 0 and division by 0.0 to both result in the same exception. It also makes sense for integer division to raise rather than return a float (since "x // y" between two ints will never otherwise be a float). So it'd be nastily inconsistent to return a NaN for float division by zero. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
