Mark Dickinson added the comment:
Just to confirm the above:
In 2.6, PyFloat_FromString in Objects/floatobject.c ends up using the
system strtod to parse "nan" and "-nan" (except that if the system
strtod fails to recognise "nan" for some reason then it returns the
result of 0.0 * Infinity inst
Mark Dickinson added the comment:
Yes, I don't think Python 2.6 had a deliberate workaround. I suspect
that it's just that one version of Python happened to use something like
0.0/0.0 to generate NaN, while another used some equivalent of
strtod("nan", ...).
I also remember noticing at some po
Stefan Krah added the comment:
I hope this won't be getting too complex. :)
Firstly, I agree that this is perhaps not a bug at all. I reported it
because I seemed possible that Python2.x had a deliberate workaround for
this issue which somehow got lost in 3.x.
Secondly, I didn't mention that I
Mark Dickinson added the comment:
You may have let yourself in for something here. :-)
Can you tell me what:
>>> import sys
>>> print sys.float_repr_style
gives for your Opensolaris/suncc/Python3.x combination? If it prints
'legacy', then I'd dearly like some help with making it read 'shor
New submission from Stefan Krah :
Sorry to report so many obscure corner cases. With the combination
Opensolaris/suncc/Python3.x copysign() gives reversed results when the
second argument is a NaN. The bug is in the C99 copysign() function
(OpenSolaris/suncc), but Python2.6 seems to have a workar
