[Donn Cave] > I ran into a phenomenon that seemed odd to me, while testing a > build of Python 2.4.1 on BeOS 5.04, on PowerPC 603e. > > test_builtin.py, for example, fails a couple of tests with errors > claiming that apparently identical floating point values aren't equal. > But it only does that when imported, and only when the .pyc file > already exists. Not if I execute it directly (python test_builtin.py), > or if I delete the .pyc file before importing it and running test_main().
It would be most helpful to open a bug report, with the output from failing tests. Can't guess much from the above. In general, this can happen if the platform C string<->float routines are so poor that eval(repr(x)) != x for some float x, because .pyc files store repr(x) for floats in 2.4.1. The 754 standard requires that eval(repr(x)) == x exactly for all finite float x, and most platform C string<->float routines these days meet that requirement. > For now, I'm going to just write this off as a flaky build. I would > be surprised if 5 people in the world care, and I'm certainly not one > of them. I just thought someone might find it interesting. There are more than 5 numeric programmers even in the Python world <wink>, but I'm not sure there are more than 5 such using BeOS 5.04 on PowerPC 603e. > The stalwart few who still use BeOS are mostly using Intel x86 hardware, > as far as I know, but the first releases were for PowerPC, at first > on their own hardware and then for PPC Macs until Apple got nervous > and shut them out of the hardware internals. They use a Metrowerks > PPC compiler that of course hasn't seen much development in the last > 6 years, probably a lot longer. The ultimate cause is most likely in the platform C library's string<->float routines (sprintf, strtod, that kind of thing). -- http://mail.python.org/mailman/listinfo/python-list