Does Python need a '>>>' operator?

[Bengt Richter]

On Mon, 15 Apr 2002 17:27:09 +1200, Greg Ewing <greg at cosc.canterbury.ac.nz> wrote:

>Bengt Richter wrote:
>> 
>> On thinking about it, I think this is ugly, though probably
>> convenient in the implementation. I.e., looking at the bits
>> of the absolute value is not usually what you really want when
>> you convert to hex, IMO.
>
>The way I see it, if you're doing bit twiddling
>using unified ints/longs, you should always be
>working with *positive* integers, in which case
>the hex representation will always be what
>you want.
>
>The only reason negative integers come into
>the picture now is that setting bit 31 of a
>non-long int has the side effect of making it
>negative. Once ints and longs are unified,
>this presumably will no longer happen.
>
But surely there will still be negative integers,
whether generated by a wart mechanism or simply by
unary minus etc. So I take it you would like to use the
current sign-magnitude long hex representation, with
the L dropped for unification?

Bit-twiddling operations on integers don't make sense in terms
terms of the actual numerical values (except perhaps 0 and 1
cast as bools), so there's really an implicit mapping from the
integers to something else where it can make sense.

One 'something else' is an array of booleans whose logical values
are represented by the 0/1 bits of the integers. You can do
this with negative numbers too. You just have to have some
convention for normalizing the boolean arrays to the same size,
given two integers. One consistent convention would be to
say the bit array extends indefinitely by sign extension, with the
extended sign represented by as many bits as it takes to normalize
the two arrays to the same length. Operations then proceed between
corresponding array elements, and then the result maps back to integer,
with the topmost bit still being interpreted as representing indefinitely
extendeded sign bits.

For this kind of interpretation, I would prefer to have the hex based
on the bit arrays, not sign/magnitude. In particular, the ~ operation
also changes the sign bit, and to me,

 >>> hex(~4)
 '0xfffffffb'

is more informative and useful than
 >>> hex(~4L)
 '-0x5L'

The former just needs a convention for eliminating redundant high
end bits in the representation (which I think have to be assumed
indefinitely extended unless you subclass to a fixed width).
(Perhaps int could become a platform dependent 32 or 64-bit wide
subclass of unified integer? (just an instant idea, not thought through ;-))

Regards,
Bengt Richter