[Python-Dev] Octal literals

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.

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

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

```