Does Python need a '>>>' operator?

[Bengt Richter]

On Mon, 15 Apr 2002 08:19:01 -0700, "Ken Peek" <Ken.Peek at SpiritSongDesigns.comNOSPAM> wrote:
[...]
>"Martin v. Loewis" <martin at v.loewis.de> wrote in message
>news:m3lmbpoyai.fsf at mira.informatik.hu-berlin.de...
>
>| "Ken Peek" <Ken.Peek at SpiritSongDesigns.comNOSPAM> writes:
>|
>| > 2) Secondly, when we are printing integers in the hex format,
>| > we are not interested in the sign-- we are looking at the
>| > bit pattern.
>|
>| Who is this "we" in this statement? When I print numbers in hex, I'm
>| interested in the hexadecimal representation if the number. For
>| *printing* it, I usually don't care what the internal representation
>| is.
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.

The abstraction comes into play because we have a legacy of using integers
as e.g., arrays of booleans with effective reinterpret-casts back and forth. But
there are valid and useful abstractions behind that. 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.

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.

>
>That would be most people that need to get inside and take a look at the bit
>representation of a number-- when doing things like developing new random nubmer
>generators, and encryption techniques.  There are other examples of course, but
>you should get the idea.  When _I_ want to se a number in hex, it is because I
>am interested in the bit pattern.  I'm sure many others feel the same way about
>it.  I have only been programming for 30 years, (professionally for 25)-- so
>maybe I don't have enough experience to give you the right answer to this.
Calm down, sonny ;-) (I've been at it since '59 ;-)

>
>| > 3) With unification, the long and the int types should not
>| > print differently when calling the 'hex()' method.
>|
>| And indeed, they won't.
>|
>| > (The 'int' version of this method NEVER has, and shouldn't print a
>| > minus sign, and _I_ don't think the long version of 'hex()' should
>| > either.  This _is_ what needs to happen to have proper unification.
>|
>| The PEP currently says differently:
>|
>| # In most cases the long int semantics will prevail; however, the
>| # trailing 'L' from long int representations will be dropped.
>|
>| This clearly says that the long int semantics will prevail.
>
>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.

>I will say it again: when I am printing a number in hexadecimal, I am interested
>in the _BIT_PATTERN_ -- _NOT_ the numeric _VALUE_.  I'm sure many others feel
>this way as well.
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).

>
>| > 4) We are not using 1.5.2 anymore.  We are on 2.2.x now.
>| > You need to imprint on your brain that there now should be
>| > _NO_ visible difference (to the programmer) between the long
>| > and the int type.  In fact, the int and long representations
>| > are now just an implementation detail, and should be hidden,
>| > and transparent to the programmer.
>|
>| I completely agree.
>|
>| > Martin, why do you resist the unification of these two
>| > types for _ALL_ operations and methods?
>|
>| Why did you conclude that I resist? I'm just saying that the long
>| semantics will prevail, not the int semantics.
>
>Again-- when this change is made, I think it will be a Python "_WART_".
                                           ^^
Which 'it' do you mean? Personally, I agree on the hex print issue (though
not with your reference to what the implementation 'knows' about how many
bits happen to be used in reresenting longs -- the abstract values have
indefinitely extended sign bits).

>Numbers should only print the sign and magnitude when printing decimal numbers.
>When printing hexadecimal numbers, the bit pattern is what is needed-- not the
>sign and magnitude.
I agree, but there needs to be a convention for representing indefinitely extended
sign bits, and that is hard to do with backwards compatibility. So I suggest that
0x be used as planned and an alternate hex representation be introduced using 0h
as the prefix and the msb of the top hex digit is considered indefinitely extended.
This means that positive numbers with msb in position 4*b-1 (numbering from 0 at lsb)
will need a prefixed zero hex digit, E.g, 0h09 == +9, but 0h9 == -7.
>
>wart- Wart- WART- WWAAARRTT!!!!!
>

Regards,
Bengt Richter