[Python-Dev] Deprecation warning on integer shifts and such
Martin v. Loewis
13 Aug 2002 09:07:49 +0200
Oren Tirosh <firstname.lastname@example.org> 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
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.