[Python-Dev] Octal literals

[Bengt Richter]

On Tue, 31 Jan 2006 17:17:22 -0500, "Andrew Koenig" <ark at acm.org> wrote:

>> Apart from making 0640 a syntax error (which I think is wrong too),
>> could this be solved by *requiring* the argument to be a string? (Or
>> some other data type, but that's probably overkill.)
>
>That solves the problem only in that particular context.
>
>I would think that if it is deemed undesirable for a leading 0 to imply
>octal, then it would be best to decide on a different syntax for octal
>literals and use that syntax consistently everywhere.
>
>I am personally partial to allowing an optional radix (in decimal) followed
>by the letter r at the beginning of a literal, so 19, 8r23, and 16r13 would
>all represent the same value.
In that case, could I also make a pitch for the letter c which would similarly
follow a radix (in decimal) but would introduce the rest of the number as
a radix-complement signed number, e.g., -2, 16cfe, 8c76, 2c110, 10c98 would
all have the same value, and the sign-digit could be arbitrarily repeated to
the left without changing the value, e.g., -2, 16cfffe, 8c776, 2c1110, 10c99998
would all have the same value. Likewise the positive values, where the "sign-digit"
would be 0 instead of radix-1 (in the particular digit set for the radix). E.g.,
2, 16c02, 16c0002, 8c02, 8c0002, 2c010, 2c0010, 10c02, 10c00002, etc. Of course
you can put a unary minus in front of any of those, so -16f7 == 1609, and
-2c0110 == -6 == 2c1010 etc.

This permits negative literal constants to be expressed "showing the bits"
as they are in two's complement or with the bits grouped to show as hex or
octal digits etc. And 16cf80000000 would become a 32-bit int, not a long as
would -0x80000000 (being a unary minus on a positive value that is promoted to long).

Regards,
Bengt Richter