On Sat, 30 Apr 2011 08:02:33 +0100 Mark Dickinson <dicki...@gmail.com> wrote: > On Fri, Apr 29, 2011 at 2:18 AM, Greg Ewing <greg.ew...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com