[Python-Dev] Negative long literals (was Re: Does Python need a
Mon, 10 Jun 2002 09:08:36 -0400
>> 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>).
> 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)
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>.