Home Original page

Does Python need a '>>>' operator?

Ken Peek Ken.Peek at SpiritSongDesigns.comNOSPAM
Mon Apr 15 22:45:00 EDT 2002 
"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.
|
| 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

This would be too much of a pain in the ass (for me at least.)  See my later
post, where I give examples.
More information about the Python-list mailing list