[Python-Dev] Octal literals

[Gustavo J. A. M. Carneiro]

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