Does Python need a '>>>' operator?

[Ken Peek]

"David Eppstein" <eppstein at ics.uci.edu> wrote in message
news:eppstein-9E09EB.21122714042002 at news.service.uci.edu...
| In article <3cba4cf7 at news.mhogaming.com>,
|  "Ken Peek" <Ken.Peek at SpiritSongDesigns.comNOSPAM> wrote:
|
| > The other thing I was trying to say, is that if this
_BUG_
| > (gee- that wasn't so hard!) in Python is fixed, then we
need
| > a way to consistently do all of this bit shifting.  Now
that
| > ints and longs are 'unified', you are supposed to be
able to
| > write code that doesn't care what the internal
| > representation is-- that should also apply to the '<<'
and
| > '>>' operators.  BUT, since we NOW don't know where the
high
| > bit is (but the class that is managing the long object
| > DOES), we need a '>>>' operator to consistently handle a
| > logical right shift-- (i.e.: there is no way to code
this
| > behavior in Python.)
|
| There is no "highest nonzero bit" -- if it's a negative
number, the bits
| in all sufficiently high positions are nonzero.  The long
class code
| doesn't know where the highest meaningful bit is in an
value that is
| being used as a bitstring, it only knows where the highest
| explicitly-represented bit is, and that's not the same
thing.
|
| If you do somehow know where the highest meaningful bit
is, you can
| always do something like this:
|
| def shiftLeftMasked(x, shiftAmount, highBitPosition):
|     return (x & ((1L << highBitPosition) - 1)) >>
shiftAmount
|
| --
| David Eppstein       UC Irvine Dept. of Information &
Computer Science
| eppstein at ics.uci.edu http://www.ics.uci.edu/~eppstein/

The point that I was trying to make, is that the method that
is creating the hexadecimal string (the __str__ method?)
inside
the long class is the ONLY thing that "knows" how many bytes
are being used to represent a long.  When "hex(x)" creates a
string from a long, it should not have a '-' sign if the
long
is negative, but rather should print out the hexadecimal
representation of the number in using the number of bytes
that
the object currently occupies.  If we are printing a long as
a
decimal number, then we DO add the '-' sign.

The method that "owns" the object, and shifts the long
('<<',
'>>', '>>>') can most certainly determine how many bytes are
being used to represent the object, and can most certainly
provide the correct answer for these operations.  The USER
of
the object cannot do this from outside code however, so the
method inside the long class will have to be fixed to repair
this errant behavior.

I think the unification of longs and ints is a wonderful
thing,
but the work it not finished yet-- some more careful thought
needs to be put into this-- in fact, an int is promoted to a
long (as you pointed out) by the multiply operation, but not
the
shift operation.  This is indeed a BUG.  What is ALSO a BUG,
is
that the long is then not DEMOTED back to an int, when it is
divided by either a right shift or a divide operation, and
the
number can _NOW_ be properly represented by an int.  This
should all happen automatically, "under the hood" (so to
speak)
without the programmer even having to think about it.  That
was
the whole purpose of the int-long unification, wasn't it?