Alexander Belopolsky writes:
On Fri, Apr 29, 2011 at 3:30 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Rob Cliffe writes:
> True. But why be forced to walk on eggshells when writing a perfectly > ordinary bit of code that "ought" to work as is?
What makes you think *anything* "ought" to "work" in the presence of NaNs?
There are different shades of "not working". In most cases, raising an exception is preferable to silently producing garbage or entering an infinite loop. NaNs are unordered and NaN < 0 makes as much sense as None < 0 or "abc" < 0. The later operations raise an exception in py3k.
Sure, Python's behavior when asked to perform mathematical operations that do not admit a usable definition can be improved, to the benefit of people who write robust, high performance code. I appreciate your contribution to that discussion greatly. But I really doubt that raising here is going to save anybody's eggshells. The cure you suggest might be better than silent garbage or an infinite loop, but in production code you will still have to think carefully about preventing or handling the exception. Not to mention finding a way to produce NaNs in the first place. That's far from what I would call "perfectly ordinary code working as is".