[Tim] > What's the plan for removing this stuff again when UnixWare fixes > their bugs? [Martin v. Loewis] > There is no plan for that at the moment. Please have a look at > > http://sf.net/tracker/?group_id=5470&atid=305470&func=detail&aid=450710 > > for prior discussion on the matter; Ya, I knew about that -- it was a rhetorical question <wink>. > [wishful thinking deleted] For platforms that Python developers build on every day (Linux and Windows, possibly Macs), and tens or hundreds of thousands of people run on, such #ifdef crud probably will go away someday, but I suspect these temporary UnixWare hacks will infect the code base forever. So I'd rather let tests fail there, and simply note in the README that such failures are due to UnixWare bugs and will go away when UnixWare fixes them. That's what we do with, e.g., SGI -O bugs. As is, the code is obfuscated forever, and may well just be swapping one set of bugs for another. For example, the replacement for atan2 isn't correct, as it ignores the sign of the zero, and atan2 on a 754 box should pay attention to that. >>> from math import atan2 >>> z = 0.0 >>> atan2(z, -1) 3.1415926535897931 >>> atan2(-z, -1) -3.1415926535897931 >>> So now we've got a different UnixWare bug, which will persist even after UnixWare fixes *their* errors because we're #ifdef'ing their implementation away. I don't view that as a problem unique to this patch set, but as a predictable (in outline) consequence of trying to worm around minority-platform bugs via #ifdef.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4