Does Python need a '>>>' operator?

[Ken Peek]

"Greg Ewing" <greg at cosc.canterbury.ac.nz> wrote in message
news:3CBA64AD.AE4C563D at cosc.canterbury.ac.nz...
| Bengt Richter wrote:
| >
| > On thinking about it, I think this is ugly, though probably
| > convenient in the implementation. I.e., looking at the bits
| > of the absolute value is not usually what you really want when
| > you convert to hex, IMO.
|
| The way I see it, if you're doing bit twiddling
| using unified ints/longs, you should always be
| working with *positive* integers, in which case
| the hex representation will always be what
| you want.
|
| The only reason negative integers come into
| the picture now is that setting bit 31 of a
| non-long int has the side effect of making it
| negative. Once ints and longs are unified,
| this presumably will no longer happen.

"presumably" ???

Well, WILL it, or WON'T it?  The functioning of ints and longs
should be completely transparent to the programmer, using ANY
operator, and the printing of the value in hexadecimal should
also not be different.

"presumably" just doesn't cut the mustard with me.  Unification
should unify everything-- not just "some" operations...

When you multiply an int that has the value: 0x40000000 by 2,
you get 0x80000000L --- which is just as it should be.  BUT,
when you now divide it by 2, it should change back to an int.
This should all happen automagically, "under the hood", without
the programmer even having to worry about it.

When you create a string of a long using the hex() method, the
'-' sign should not even be printed-- you should rather get the
true number of bytes (in twos-complement hexadecimal) that are
currently being used to contain the object.

These are some of the things that need to happen _IF_ we truly
want seamless unification of the int and long types.