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

Gustavo J. A. M. Carneiro gjc at inescporto.pt
Wed Feb 1 13:33:36 CET 2006

On Tue, 2006-01-31 at 17:17 -0500, Andrew Koenig 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.

+1, and then issue a warning every time the parser sees leading 0 octal constant instead of the new syntax, although the old syntax would continue to work for compatibility reasons.

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.

For me, adding the radix to the right instead of left looks nicer: 23r8, 13r16, etc., since a radix is almost like a unit, and units are always to the right. Plus, we already use suffix characters to the right, like 10L. And I seem to recall an old assembler (a z80 assembler, IIRC :P) that used a syntax like 10h and 11b for hex an bin radix.

Hmm.. I'm beginning to think 13r16 or 16r13 look too cryptic to the casual observer; perhaps a suffix letter is more readable, since we don't need arbitrary radix support anyway.

/me thinks of some examples:

644o # I think the small 'o' cannot be easily confused with 0 or O, but.. 10h # hex.. hm.. but we already have 0x10 101b # binary

Another possility is to extend the 0x syntax to non-hex,

0xff # hex 0o644 # octal 0b1101 # binary

I'm unsure which one I like better.

Regards,

-- Gustavo J. A. M. Carneiro <gjc at inescporto.pt> <gustavo at users.sourceforge.net> The universe is always one step beyond logic

More information about the Python-Dev mailing list