>> 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>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4