[Python-Dev] Not-a-Number

Antoine Pitrou solipsis at pitrou.net
Sat Apr 30 12:37:22 CEST 2011


On Sat, 30 Apr 2011 08:02:33 +0100
Mark Dickinson <dickinsm at gmail.com> wrote:
> On Fri, Apr 29, 2011 at 2:18 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> > Taking a step back from all this, why does Python allow
> > NaNs to arise from computations *at all*?
> 
> History, I think.  There's a c.l.p. message from Tim Peters somewhere
> saying something along the lines that he'd love to make (e.g.,) 1e300
> * 1e300 raise an exception instead of producing an infinity, but dare
> not for fear of the resulting outcry from people who use the current
> behaviour.  Apologies if I've misrepresented what he actually
> said---I'm failing to find the exact message at the moment.
> 
> If it weren't for backwards compatibility, I'd love to see Python
> raise exceptions instead of producing IEEE special values:  IOW, to
> act as though the divide-by-zero, overflow and invalid_operation FP
> signals all produce an exception.  As a bonus, perhaps there could be
> a mode that allowed 'nonstop' arithmetic, under which infinities and
> nans were produced as per IEEE 754:
> 
>     with math.non_stop_arithmetic():
>         ...
> 
> But this is python-ideas territory.

I would much prefer this idea than the idea of making NaNs
non-orderable.  It would break code, but at least it would break
in less unexpected and annoying ways.

Regards

Antoine.




More information about the Python-Dev mailing list