Does Python need a '>>>' operator?

[Beni Cherniavksy]

[OK, that thread is long dead but I din't notice how many miles of
massages I'm behind when I started reading ;-]

On 2002-04-16, Bengt Richter wrote:

> On Mon, 15 Apr 2002 21:03:45 -0400, Tim Peters <tim.one at comcast.net> wrote:
>
> >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).
>
I just got another idea: use 0x1234 for 0-filled numbers and 1xABCD for
1-filled ones.  That way you impose no restrictions on what follows the
prefix and keep backward compatibility.  0xFFFFFFFF stays a 2^n-1
_positive_ number, as it should be.  The look of 1x is weird at first but
it is very logical...

-- 
Beni Cherniavsky <cben at tx.technion.ac.il>