Does Python need a '>>>' operator?

[Tim Peters]

[Ken Peek]
> As part of the "Grand Unification of the 'int' and the
> 'long int' types", the "new Python way" (as provided to
> us by Guido,) of viewing 'long ints' is that if they are
> a positive number, then the 'long int' should behave in
> a manner as if there is an infinite number of zeros
> above the highest bit in the number, and if the 'long
> int' is negative, then the 'long int' should behave as
> if there is an infinite number of ones above the highest
> bit (i.e.: in so called "two's complement" fashion-- the
> same way a signed 'regular int' behaves.)

Yes, but that's not new:  that's *always* been how long ints have been
viewed in Python, at least since 1.0 (long before that, it went thru a brief
confusing stage of viewing long ints as being in an unbounded 1's-complement
notation; that was a mess).

> Thus-- my "expectation" is that 0x8000000000000000 >> 1
> is: 0x4000000000000000 (and that is the way Python now
> works for positive 'long ints'.)

Right.

> Given the above description of the way NEGATIVE 'long
> ints' should behave, my 'expectation' is that:
> -0x8000000000000000 >> 1 _SHOULD_ return:
> -0xC000000000000000,

Oh no -- that would be plain wrong.  You're not accounting for the "-" sign
at the start of the result.   Recalling that -x == (~x) + 1, -0x80 is an
infinite string of 1 bits followed by 7 zero bits (hex notation doesn't
really help with the visualzation).  If you shift that right by 1 bit, then
you should (clearly) get an infinite string of one bits followed by 6 zero
bits.  In binary:

...111000000

Take the complement:

...000111111

Add 1:

...001000000

Back to hex:

-0x40

In exactly the same way, for short ints today:

    (-0x80) >> 1 == -0x40

and ditto for longs:

    (-0x80L) >> 1 == -0x40L

Those are both true in every version of Python since 1.0, and will continue
to be true after int/long unification is complete.  Right shifts of a Python
integral type have never needed to care whether the input was a short or
long.  It can only make a difference for left shifts now.

> (_NOT_ -0x4000000000000000 as Python _NOW_ behaves.)

Python may not be doing what you expect, but it is doing what you're arguing
for it to do <wink>.

> The way Python _NOW_ works, is to give a different
> behavior for the '>>' operator depending on whether you
> are working on an 'int', or a 'long int'.

No -- you're getting confused by the "-" notation, and that's all.  Every
other confusion follows from that.