Does Python need a '>>>' operator?

[Joe Mason]

In article <3cbb7e33 at news.mhogaming.com>,
Ken Peek <Ken.Peek at SpiritSongDesigns.comNOSPAM> wrote:
>Quite frankly, I don't give a damn HOW the long (or int) is represented
>internally to the machine-- I simply ALWAYS want the same to interface to an
>object that behaves as if it is a twos-complement integer.  When I left shift
>it, I don't want the damn SIGN to change-- when I right shift it, I want to be
>able to CONTROL the sign bit that is shifted in, when I display the integer in
>decimal, I want a minus sign prepended to the string if the number is negative,
>and when I print out the number in hexadecimal format, I DON'T want "sign and
>magnitude"-- I simply want a string of hex digits with a '0x' prepended to them,
>representing the twos-complement form of the number, and I want 2*N hex digits
>EVERY TIME, where N is the current size of the integer (in bytes.)

As I see it, the problem here is an interface mismatch.  The fact that
integers are represented as twos-complement numbers is, most of the time,
an implementation detail.  As you point out, you don't care if it actually
*is* a bitfield, you just want the interface of one.  This is an interface 
that should definitely be available, but not necessarily for every integer:
most of the time, it's not important at all. 

So I'd argue that the ability to behave as a twos-complement bitfield is
not something a standard integer should support, and that what you need is
a bitfield object (which a constructor that takes an integer).  This could
be a new language construct or completely encapsulated in a module.  (I'd
lean towards a module, but I think that would mean that every bitwise logical
operator would become a method or function, and I can see a case being made
that keeping the operators available is important enough to be part of the
language.) 

Also, to be completely clean, any operators that currently have no use
except to treat integers as bitfields should be made to work only on
bitfield objects instead.

  x = bitfield(i)
  y = bitfield(j)
  z = x << 8 & y

or

  x = bitfield(i)
  y = bitfield(j)
  z = x.shiftleft(8).bitand(y)

All the arguments about whether doing things with sign extension is
violating the transparency of integers (in an 'it should just work' sense) 
now become invalid (or at least are confined to the constructor and any
methods to convert back to an int).  The bitfield contracts to work just
like a string of bits.

Obviously this is an unrealistic proposal: removing bitwise logical
operators isn't going to happen.  But I'm still interested, in case I
ever design a Python-like language (heh): from your point of view, would
this be acceptable or desirable?  Or would it be too much of a pain in the
ass?  (I don't work with bitfields much, but I can imagine that if you
commonly have to keep swapping back and forth between the two ways of
conceiving of a number, this would be a bad idea.)

Joe