"Tim Peters" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > All Python behavior in the presence of a NaN, infinity, or signed zero > is a platform-dependent accident.
The particular issue here is not platform dependence as such but within-platform usage dependence, as in the same code giving radically different answers in a standard interactive console window and an idle window, or when you run it the first time (from xx.py) versus subsequent times (from xx.pyc) until you edit the file again. (I verified this on 2.2, but MSpencer claimed to have tested on 2.4). Having the value of an expression such as '100 < 1e1000' flip back and forth between True and False from run to run *is* distressing for some people ;-). I know that this has come up before as 'wont fix' bug, but it might be better to have invalid floats like 1e1000, etc, not compile and raise an exception (at least on Windows) instead of breaking the reasonable expectation that unmarshal(marshal(codeob)) == codeob. That would force people (at least on Windows) to do something more more within-platform deterministic. >If marshal could reliably detect a NaN, then of course unmarshal >should reliably reproduce the NaN -- provided the platform on which >it's unpacked supports NaNs Windows seems to support +- INF just fine, doing arithmetic and comparisons 'correctly'. So it seems that detection or reproduction is the problem. Terry J. Reedy _______________________________________________ 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
