Octal notation: severe deprecation

Reinhold Birkenfeld reinhold-birkenfeld-nospam at wolke7.net
Fri Jan 14 14:13:48 EST 2005


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.

Reinhold



More information about the Python-list mailing list