[Python-ideas] Why is nan != nan?

[Bruce Leban]

I'm missing something from this discussion. Is this an academic exercise or
are there scenarios that don't work well with things as they are? It's hard
to determine if a suggested change solve the problem without knowing what
the problem is.

Here's a problem: I find it annoying that in some (other) languages there's
no easy way to trap integer overflow. It's easy to write code that's wrong
accidentally. But changing the language definition to fail when an overflow
happens would break some valid programs. In python, results that return nan
or inf aren't exactly silent failures but they are quiet. (Personally, I
would have made them non-hashable so you couldn't accidentally stick one in
a dict but that's another problem.)

Anyway, of silent/quiet failure is the issue, then what we need is a way to
make the failure not silent, e.g., wrap it in a try/except block like this
that says, convert any nans to NanErrors:

    try with NanError:
      blah
    except NanError:
      blah

Inside this scope, it might be useful to run code that does allow nans,
which means we'd also need something like:

    without NanError:
      blah

This all seems a bit too magic in how it would work. This is along the line
of Mark Dickinson's suggestion, but the default behavior should stay the
same as it is now.

--- Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100327/72c6e1de/attachment.html>