[Python-Dev] Octal literals (original) (raw)

Bengt Richter bokr at oz.net
Wed Feb 1 01:05:11 CET 2006

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

More information about the Python-Dev mailing list