Does Python need a '>>>' operator?

[Tim Peters]

[Tim]
>> Viewing longs as characteristic bit vectors, they model finite
>> and co-finite sets.

[Greg Ewing]
> Well, I meant finite bit strings,
> which is what people twiddle most of the time.

I've got nothing against complements, and the complement of a finite set is
a co-finite set -- there's no problem here.

>> Only finite sets "look positive"; co-finite sets "look negative".  It
>> doesn't take more than the unary ~ operator to go from one kind to the
>> other

> Yes, that's a bit of a nuisance. Whenever you
> do a complement, you really need to specify how
> many bits you're complementing somehow,
> e.g.
>
>   y = ~x & 0x0ffffffff

Why?  If you want to *display* the result as a hex number, that's "the
usual" way to do it (it gets rid of the minus sign in all cases).  But in
the middle of computing bitset operations, it doesn't improve semantics,
speed or clarity.  It adds brittleness, though, by injecting a notion of
maximum size where such a notion isn't needed.

> The neatest solution

Sorry, I don't "a problem".

> would be to have a special fixed-length-bit-string type. Maybe if
> array.array grows a boolean type option, we could give it
> & | ~ << >> operators too.

Different issue, and talked about quite a bit on Python-Dev over the last
few weeks.  Probably the province of Numarray (array.array's code fights
bitstrings every step of the way -- byte is its smallest natural
granularity).