> > >>> -(0xffffffff) > > 1 > > >>> -0xffffffff > > -4294967295L <<<<-------- !!! > > >>> > > This is my main concern - that there is an inconsistency between > -(0xffffffff) and -0xffffffff. Mine too. :-) > I think whatever is decided, this inconsistency should be fixed for > 2.3 (and possibly back-ported to 2.2). > > So we end up with either > > 0xffffffff == -1 > -0xffffffff == 1 > > or > > 0xffffffff == 4294967295L > -0xffffffff == -4294967295L > > and 0xffffffff is going to stay as -1 until 2.4 ... We can't do the latter; 0xffffffff was always -1, and changing it without at least giving a warning for one release is too abrupt. The problem with fixing it in 2.3 so that -0xffffffff is 1, is that it keeps changing between releases: up through 2.1 it was 1, in 2.2 it was -4294967295L, in 2.3 it would be 1 again, and in 2.4 it would be -4294967295L again!!! The only saving grace is that few people ever use such hex constants with a minus sign in front of them. But even then, I'm not sure of the back-and-forth is worth it. And while you can say, "so fix it in 2.2.3 too", that doesn't mean that everybody will upgrade. --Guido van Rossum (home page: http://www.python.org/~guido/)
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