hex and long

Robin Becker robin at jessikat.fsnet.co.uk
Sat Apr 13 05:06:56 EDT 2002


In article <mailman.1018668146.15677.python-list at python.org>, Tim Peters
<tim.one at comcast.net> writes
>[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.

whoops to late at night you're right
 
>
>> >>> 0xffffffff
>> -1
>> >>>
>>
>> clearly the second is being treated as a 32 bit int and the first as a
>> long.
>
....
thanks for the 'explanation'. It just looks odd now that we get a smooth
transition for add and multiply etc, but not for << and hex conversions. 

Is there an easy way to get back to the low 32 bits of a long or do I
have to do bit twiddling?
-simple failure is not better than complex success-ly yrs- 
Robin Becker



More information about the Python-list mailing list