[Python-Dev] Deprecation warning on integer shifts and such

[Martin v. Loewis]

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