Oren Tirosh <oren-py-d@hishome.net> writes: > The problem is that many programmers have 0xFFFFFFFF pretty much hard-wired > into their brains as -1. How about treating plain hexadecimal literals as > signed 32 bits regardless of platform integer size? The idea is that, for any sequence S of digits, S, and SL, should mean the same thing. So 0xFFFFFFFF should mean the same thing as 0xFFFFFFFFL. Programmers may have that hard-wired, but this is not a problem; a problem only arises if their code breaks. In many cases, it won't. > I think that this will produce the smallest number of > incompatibilities for existing code and maintain compatibility with > C header files on 32 bit platforms. In this case 0xff000000 will > always be interpreted as -16777216 and the 'i' parser will happily > convert it to wither 0xFF000000 or 0xFFFFFFFFFF000000, depending on > the native platform word size - which is probably what the > programmer meant. This means you suggest that PEP 237 is not implemented, or atleast frozen at the current stage. > So what's the point of having Python interpret it as 4278190080? It allows to unify ints and longs, see PEP 237. > If what I really meant was 4278190080 I can represent it portably as > 0xFF000000L and in this case the 'i' parser will complain on 32 bit > platforms - with a good reason. Yes, but the L suffix will go away one day. Regards, Martin
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