Does Python need a '>>>' operator?

Ken Peek Ken.Peek at SpiritSongDesigns.comNOSPAM
Mon Apr 15 01:18:41 EDT 2002


"Tim Peters" <tim.one at comcast.net> wrote in message
news:mailman.1018828228.8551.python-list at python.org...

| < snip! >
|
| [Ken Peek]:
| > Given the above description of the way NEGATIVE
| > 'longs' should behave, my 'expectation' is that:
| > -0x8000000000000000 >> 1 _SHOULD_ return:
| > -0xC000000000000000,
|
| < snip! >
|
| No -- you're getting confused by the "-" notation, and
that's all.  Every
| other confusion follows from that.

You may be right that I am getting confused about the hex
display of longs-- That's because the display of a hex
number with a '-' sign prepended is such a ridiculous
notion, that it didn't even dawn on me that was what was
going on.  This is very confusing and I think this is a
_BUG_.  I don't care if "Python has always done it this
way"-- it is _WRONG_, and it is a _BUG_!  This should be
fixed so that decimal display of longs uses the '-' sign,
but hex display does not (you would just get the number of
hex digits in their raw "twos complement" form that the long
object's hex display method "knows" there is...)

There is another _BUG_ in Python:

>>> 0x40000000 << 1
-2147483648

This should have been automatically converted to a long, not
a negative int.

If we _ARE_ going to unify the long and int types, then
let's bite the bullet, and DO IT RIGHT.  Even if it breaks
code that depends on this bug being there.  I shouldn't have
to worry whether it's a long or an int when I am doing ANY
operation in Python-- they should both give the expected
result with _NO_ surprises...  (In fact, there is nothing
wrong with demoting a long to an int automatically, if the
value of a result can now be held in an int.)






More information about the Python-list mailing list