Does Python need a '>>>' operator?

[Bengt Richter]

On Mon, 15 Apr 2002 21:03:45 -0400, Tim Peters <tim.one at comcast.net> wrote:

>[Bengt Richter]
>> ...
>> I just think the signed hex is not terribly useful.
>
>In practice, if I'm working with 300-bit bitsets represented as longs, I
>never do hex(x), but hex(x & mask) instead, where mask = ~(-1L << 300) (a
>string of 300 low-order bits).  Regardless of x's sign, that "shows the
>bits" in a 1-means-on 0-means-off sense.  The key is that I *know* the width
>I have in mind, much as hex(int) knows the width of a platform C long today,
>so can pull the same trick for regular ints.
>
Sure. But you can also pick a width for minus_sign-less-but-not-sign_bit-less
hex purposes by defining a normalized width that encompasses just enough bits
to show a hex 0 or F as the first digit, knowing that all to the left are
redundant duplication. (Credit to Greg Ewing for the suggestion of making sure
it's always a reader-friendly leading 0 or F to indicate sign, vs. my ensuring
just an msb of 0 or 1 within the ms hex digit).

The current hex output also normalizes out leading duplicate sign bits, in effect.
what I am suggesting is just a differently normalized hex representation, and you
don't need to specify width nor create a positive number just to see the bits.

I recognize backwards compatibility problems with using 0xF9 to mean -7, so I
have been saying we could us 0h in place of 0x, so that -0x7 (unified L semantics)
can live along side the equivalent 0hF9.

BTW, if I wanted several looks at 300-bit numbers in hex, I'd probably use '%075x'.
Any plans for modifying this when there's no implied int widths at all?:

 >>> '%016X' % -3
 '00000000FFFFFFFD'
 >>> '%016X' % -3L
 '-000000000000003'

I'd like the unified result here (where we _are_ specifying a width and prefixing after all ;-)
to be:

 >>> '%016H' % -3
 'FFFFFFFFFFFFFFFD'

and if we don't specify width, it could be normalized down to

 >>> '%H' % -3
 'FD'

(I faked those, of course).
Regards,
Bengt Richter