Does Python need a '>>>' operator?

[Ken Peek]

"Martin v. Loewis" <martin at v.loewis.de> wrote in message
news:m3zo07yxap.fsf at mira.informatik.hu-berlin.de:

| > >>> b = -a
| > >>> print hex(b >> 1)
| > -0x4000000000000000L
| >
| > # !!! SURPRISE !!!
| > # (I expected -0xC000000000000000L !!!)
|
| Can you explain why you expected this? How could Python
| possibly know how many bits you expected to be in the
| internal representation?
|
| Can you elaborate? You explained that the >>> fills in
| zeroes for 32-bit numbers that have the highest bit
| set. With long integers, you don't need that: If you
| have a number that has the 2**31 bit set, it may still
| be a positive number, and right-shifting will fill in
| the zero bit. So no need for a >>> operator.

OK--

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.)

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

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

(_NOT_ -0x4000000000000000 as Python _NOW_ behaves.)

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'.  This was OK
before, because the 2 object types were treated
differently by the language.  I thought we were trying
_NOW_ (versions >= 2.2.x) to "unify" the behavior of
'ints' and 'long ints'.

Am I wrong?

Now, if I am right about this, then we don't really
know if we are right shifting an 'int', or a 'long int'
and so it would be 'useful' to have a '>>>' operator in
this case, to guarantee that zeroes are shifted into
the highest bit.  JAVA has this facility, why must
Python _NOT_ have it?