Does Python need a '>>>' operator?

[John Roth]

"Joe Mason" <jcmason at student.math.uwaterloo.ca> wrote in message
news:a9fvvl$nr4$1 at watserv3.uwaterloo.ca...
> 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.

I think you've hit the root of the issue: integers are not the same as
bit strings. We tend to get confused because most hardware architectures
treat them the same when it gets down to machine representation.

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

I don't know whether there is really any need for bitfields to behave
as integers, or vice versa. If so, I presume that int() on a bitfield
instance, and bitfield() on an integer would do the job.
>
> 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.

That would break backwards compatiblity, so it won't happen.

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

Actually, it's a good proposal, except for removing the operations
from integers. It's got all of the hallmarks of something that could
happen: it can be implemented as a new type, doesn't involve
any new keywords, it can be prototyped independently of changes
to the python core, etc.

John Roth
>
> Joe