Does Python need a '>>>' operator?

[Ken Seehof]

Beni Cherniavsky <cben at tx.technion.ac.il> wrote:
> 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...

Hey, that's pretty clever.  I like it.  One objection I can forsee is
that it does add another little thing to learn.  And yes, one must
consider such a feature as making python more complex if it requires
a paragraph to be added to the main documentation, even if the feature
will only be used by "advanced" programmers.  The standard argument
is that all python programmers have to be able to read your code.

However, I don't see this as making life much more complicated for
beginners, since we already have 0x1234, which is only familiar to
experienced programmers.  People who are not familiar with 0x1234 can
learn about 1xABCD at the same time.  People who are familiar with
0x1234 (e.g. from programming in C/C++), can probably handle looking up
the proposed syntax in the documentation, if they can't guess what it
means by experimenting in the interactive interpreter.

In particular, I like:

  1xF == -1

Seems more pythonic than 0xFFFFFFFF, since the latter implies knowledge
that we are using 32 bits.  I don't know of any current way to express
1 filled binary numbers cleanly.

Unfortunately, I don't see an easy way to clean up this blemish:

>>> 0xffff
65535
>>> 0xffffffff
-1
>>> 0xfffffffff
68719476735L

I suppose in a perfect world, 0xffffffff would be 4294967295L, but
we'd have serious compatibility issues with that (note that one
would use 1xf instead of 0xffffffff to represent -1 in the perfect
world).

BTW, note that 0xffffffff == 4294967295L would be consistent with
C/C++ with an unsigned int (32 or more bits).  The idea is that
all numbers 0x... are non-negative, while number 1x... are negative.

I'm quite certain that any proposed solution (such as issuing a
warning for 0xXXXXXXXX) will receive flames, so I think I will
stop here, hoping it's not too late :-)

- Ken Seehof