[Python-Dev] Octal literals

[Bengt Richter]

On Thu, 2 Feb 2006 15:26:24 -0500, James Y Knight <foom at fuhm.net> wrote:

>On Feb 2, 2006, at 7:11 PM, Bengt Richter wrote:
>> [1] To reduce all this eye-glazing discussion to a simple example,  
>> how do people now
>> use hex notation to define an integer bit-mask constant with bits
                                 ^^^^^^^  
>> 31 and 2 set?                    |
>                                   |
>That's easy:                       |
>0x80000004                         |
 >>> 0x80000004                     |
 2147483652L                        |  
           ^------------------------'

That didn't meet specs ;-)

>
>That was broken in python < 2.4, though, so there you need to do:
I agree it was broken, but
>MASK = 2**32 - 1
>0x80000004 & MASK
does not solve the problem of doing correctly what it was doing (creating
a mask in a signed type int variable, which happened to have the sign bit set).
So long as there is a fixed-width int different from long, the problem will reappear.

>> (assume 32-bit int for target platform, counting bit 0 as LSB and
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^        
>> bit 31 as sign).
   ^^^^^^^^^^^^^^
>
>The 31st bit _isn't_ the sign bit in python and the bit-ness of the
>target platform doesn't matter. Python's integers are arbitrarily 
>long. I'm not sure why you're trying to pretend as if python was C.
Evidently I haven't made myself clear to you, and your mind reading wrt
what I am trying to pretend is definitely flawed (and further speculations
along that line are likely to be OT ;-)

So long as we have a distinction between int and long, IWT int will be fixed width
for any given implementation, and for interfacing with foreign functions it will
continue to be useful at times to limit the type of arguments being passed.

To do this arms-length C argument type control, it may be important to have constants
of int type, knowing what that means on a given platform, and therefore _nice_ to be able
to define them directly, understanding full well all the issues, and that there are workarounds ;-)

Whatever the fixed width of int, ISTM we'll have predictable type promotion effects
such as

 >>> width=32
 >>> -1*2**(width-2)*2
 -2147483648
vs
 >>> -1*2**(width-1)
 -2147483648L

and

 >>> hex(-sys.maxint-1)
 '-0x80000000'
 >>> (-int(hex(-sys.maxint-1)[1:],16)) ==  (-sys.maxint-1)
 True
 >>> (-int(hex(-sys.maxint-1)[1:],16)) ,   (-sys.maxint-1)
 (-2147483648L, -2147483648)
 >>> type(-int(hex(-sys.maxint-1)[1:],16)) ==  type(-sys.maxint-1)
 False
 >>> type(-int(hex(-sys.maxint-1)[1:],16)) ,   type(-sys.maxint-1)
 (<type 'long'>, <type 'int'>)


[1] Even though BTW you could well define a sign bit position abstractly for any
integer value. E.g., the LSB of the arbitrarily repeated sign bits to the left
of any integer in a twos complement representation (which can be well defined abstractly too).
Code left as exercise ;-)

Bottom line: You haven't shown me an existing way to do "16r80000004" and produce the int ;-)

Regards,
Bengt Richter