hex and long

[Tim Peters]

[Robin Becker]
> In 2.2 I find the following peculiarity
>
> >>> 0xffffffff
> 68719476735L

That looks an error in transcription; I expect you dropped an "f" character
in the input.

> >>> 0xffffffff
> -1
> >>>
>
> clearly the second is being treated as a 32 bit int and the first as a
> long.

Yes.  For more, see PEP 237:

    http://www.python.org/peps/pep-0237.html

> Do I have to be careful with bit 31?

Yes, and that's always (not unique to 2.2) been true on 32-bit boxes.

> What happens on 64 bit machines?

It depends on which 64-bit machine you're talking about.  On one where
sizeof(long)==8, both literals above are positive Python ints; on one where
sizeof(long)==4, same as on a 32-bit box (the first a positive long, the
second a negative regular, int).  If Python has any users left by the time
PEP 237 is fully implemented, they'll enjoy platform-independent results;
however, that can't be achieved without changing the platform-dependent
results currently exposed.

In the meantime you can force interpretation as a postive integer literal
across all platforms by appending "L" to your hex and octal literals.