Does Python need a '>>>' operator?

[Martin v. Loewis]

"Ken Peek" <Ken.Peek at SpiritSongDesigns.comNOSPAM> writes:

> When I print it out in hexadeciaml, I want the bit representation of
> a 'binary twos-complement' number, of a size (in bytes) that will
> represent the number without truncation (regardless of HOW the
> number is stored inside the machine.)

That is impossible to implement. A negative number has an infinite
amount of leading ones, so you *have* to truncate if you want a finite
hex representation.

> Let me clarify the above-- the '>>' should behave in a manner such
> that the sign bit is COPIED to the high bit during a right shift.

An integer does not have a high bit.

> So-- if the number starts out as a positive number, it STAYS a
> positive number after the shift.  The proposed '>>>' operator forces
> a zero into the high bit

Again, an integer does not have a high bit - it is infinitely many
bits. Of course, the internal representation is finite - but we agreed
to ignore the internal representation.

> # b is now a long, equal to: 0x008642130c, or the
> # equivalent of 5 bytes (no matter HOW it is
> # represented internally.)  This is because we need
> # the extra byte to convey the sign.  

If you think that numbers are conceptually represented in two's
complement, we need infinitely many bytes to represent this number,
not just five. Which number would 0x08642130c represent? 0x8642130c?

> # THIS is what _I_ expect--  the number of "bytes"
> # (or at least the equivalent) is still the same,
> # and we can see that the number is now negative,

Why do you think that abstraction should use units of 8 bits, if we
agree that the internal representation should not matter? Why not
units of, say, 11 bits? 16?

> This is how _I_ believe things should work.

It can't work meaningfully that way.

Regards,
Martin