Does Python need a '>>>' operator?

[Ken Peek]

"Martin v. Loewis" <martin at v.loewis.de> wrote in message
news:m3662sk6xo.fsf at mira.informatik.hu-berlin.de...
| bokr at oz.net (Bengt Richter) writes:
|
| > IMO 'internal representation' is a red herring. We have an abstract
| > concept of number representation (twos complement) that corresponds
| > to many hardware devices' usage, but it is the abstraction that is
| > important IMO, not the hardware.
|
| Yes, but this notion is inherently bound with the notion of "size" of
| an integer, atleast in the signed variant (for unsigned integers,
| there is no need for twos complement). If you create the complement,
| you have to know how many bits to invert.
|
| I absolutely agree with your (earlier) conclusion that bit arithmetic
| is best done with unsigned numbers.
|
| > When looking at integers cast as arrays of booleans, hex provides a
| > representation, but w.r.t. boolean values it is not very useful to
| > print it as base-16 integer with sign+absolute value.
|
| I also agree.
|
| > If I infer correctly, Ken is arguing that hex is more often used to
| > view the boolean aspect of integers than their numeric
| > aspect. That's true for me too.
|
| And so it is for me. Still, I disagree that a display of a hex number
| with a sign is illogical or incorrect. In fact, when talking about
| "unbounded" numbers, it is illogical to assume twos complement.
|
| > >Yes-- I read the PEP too-- when this happens, I will consider it a
| > >Python "_WART_", and will set about inventing ways around it for my
| > >own use.  I have forgotten more computer languages than most people
| > >will ever learn-- an I have NEVER found printing a hexadecimal
| > >number in sign and magnitude format to be useful...
| >
| > I'll second that.
|
| At a minimum, you need to propose an alternative behaviour then. I
| must say that I don't find the proposed behaviour of mandatory leading
| zeroes (the 0h proposal) very intuitive, or following tradition.
|
| Instead, there is a simple solution: use unsigned numbers if you want
| to represent bit arrays.
|
| > I would guess so. I do. But for language purposes my preference is
| > to refer to an abstract bit pattern, not hardware (even though
| > hardware mappings will exist and be useful).
|
| That is only meaningful for positive numbers - it just doesn't work
| for twos complement.
|
| Regards,
| Martin

Ahhhh!!!  Got'cha!!!!

Python DOESN'T HAVE UNSIGNED NUMBERS!!!

AND-- the PEP clearly states that (maybe in the future for efficiency) when the
internal representation of a long (most likely that has just been assigned to)
can be represented by an int, then the run-time system is at liberty to convert
it to an int.  Since there is no way to know this happened to or object, we
either have to make an overly complex "Rube Goldberg" type exploration, if we
want to be able to do a logical right shift of an int-long object.  THAT is the
reason for the '>>>' operator-- the designers of Java got rid of unsigned
integers, because many programming mistakes happened in 'C' with them in
existence-- this (in turn) necessitated the creation of a different operator for
'arithmetic right shift', and 'logical right shift'.

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

Is what I want so EVIL that Python can't do things that way?