Octal notation: severe deprecation
Bengt Richter
bokr at oz.net
Fri Jan 14 17:29:01 EST 2005
On Fri, 14 Jan 2005 20:13:48 +0100, Reinhold Birkenfeld <reinhold-birkenfeld-nospam at wolke7.net> wrote:
>Bengt Richter wrote:
>> On Thu, 13 Jan 2005 08:18:25 -0500, Peter Hansen <peter at engcorp.com> wrote:
>>
>>>and-google at doxdesk.com wrote:
>>>> In Mythical Future Python I would like to be able to use any base in
>>>> integer literals, which would be better. Example random syntax:
>>>>
>>>> flags= 2x00011010101001
>>>> umask= 8x664
>>>> answer= 10x42
>>>> addr= 16x0E800004 # 16x == 0x
>>>> gunk= 36x8H6Z9A0X
>>>
>>>I think I kinda like this idea. Allowing arbitrary values,
>>>however, would probably be pointless, as there are very
>>>few bases in common enough use that a language should make
>>>it easy to write literals in any of them. So I think "36x"
>>>is silly, and would suggest limiting this to 2, 8, 10, and
>>>16. At the very least, a range of 2-16 should be used.
>>>(It would be cute but pointless to allow 1x000000000. :-)
>>>
>> My concern is negative numbers when you are interested in the
>> bits of a typical twos-complement number. (BTW, please don't tell me
>> that's platform-specific hardware oriented stuff: Two's complement is
>> a fine abstraction for interpreting a bit vector, which is another
>> fine abstraction ;-)
>>
>> One way to do it consistently is to have a sign digit as the first
>> digit after the x, which is either 0 or base-1 -- e.g., +3 and -3 would be
>>
>> 2x011 2x101
>> 8x03 8x75
>> 16x03 16xfd
>> 10x03 10x97
>
>Why not just -2x11? IMHO, Py2.4 does not produce negative values out of
>hex or oct literals any longer, so your proposal would be inconsistent.
>
Inconsistent with what? This is a new based-literal representation, not
the old hex or octal representation. It is separate and self-consistent,
and can live along side the old.
The fact that there is no longer a way to represent negative numbers
with traditional octal or hex is due to getting away from the
platform-dependent assumptions that bit 31 was a sign bit of a 32-bit
two-s complement machine represenentation. That was a good thing to get
away from.
But it means you now have to write a unary minus expression for negative numbers,
not a self-contained literal.
Re your question, -2x11 is the same as -(2x11) so you have to decide what
you want 2x11 to mean. If it means +3, we are back to the original problem
of having no way to see any of the 111111111111....101 or ffff....fd of a -3 ;-)
(Except of course by '%02x'%(-0x3&0xff) -- ick)
I am not proposing a change to the new Py2.4 positive-only hex and octal literals.
I just want to be able to write literals for both positive and negative numbers
as self-contained literals (not expressions) without a '-' sign, and have the
representation be a readable representation of typical twos-complement representation.
You can't do that with -0x3, because (though the expression equals -3) it doesn't show
the information about the bits that you get with 16xfd or 2x101. Note that -16xfd == 16x03
and -2x101 == 2x011 and -16x03 == 16xfd and -2x011 == 2x101.
The '-' sign is not part of the literal.
Regards,
Bengt Richter
More information about the Python-list
mailing list