[Python-Dev] Negative long literals (was Re: Does Python need a '>>>' operator?)

[Tim Peters]

>> I think Beni has a very nice idea here, especially for people who can't
>> visualize 2's-complement (not mentioning Guido by name <wink>).

[Guido]
> In fact it's so subtle that I didn't notice what he proposed.  I
> though it had to do with the uppercase of 1xABCD.
>
> Maybe that's too subtle?

In context, it was part of a long thread wherein assorted people griped that
they couldn't visualize what, e.g.,

>>> hex(-1L << 10)
'-0x400L'
>>>

means, recalling that hex() is often used when people are thinking of its
argument as a bitstring.  1xc00 "shows the bits" more clearly even in such
an easy case.  In a case like '-0xB373D', it's much harder to visualize the
bits, and this will grow more acute under int-long unification.  Right now,
hex(negative_plain_int) shows the bits directly; after unification,
hex(negative_plain_int) will likely have to resort to producing "negative
literals" as hex(negative_long_int) currently does.

> Do we really need this?

No, but I think it would make unification more attractive to people who care
about this sub-issue.  The 0x vs 1x idea grew on me the longer I played with
it.  Bonus:  we could generalize and say that integers beginning with "1"
are negative octal literals <wink>.