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

Bob Ippolito bob at redivi.com
Fri Feb 3 11:40:54 CET 2006

On Feb 3, 2006, at 2:07 AM, Nick Coghlan wrote:

Bengt Richter wrote:

On Fri, 3 Feb 2006 10:16:17 +1100, "Delaney, Timothy (Tim)" <tdelaney at avaya.com> wrote:

Andrew Koenig wrote:

I definately agree with the 0c664 octal literal. Seems rather more intuitive. I still prefer 8r664. The more I look at this, the worse it gets. Something beginning with zero (like 0xFF, 0c664) immediately stands out as "unusual". Something beginning with any other digit doesn't. This just looks like noise to me. I found the suffix version even worse, but they're blown out of the water anyway by the fact that FFr16 is a valid identifier. Are you sure you aren't just used to the x in 0xff? I.e., if the leading 0 were just an alias for 16, we could use 8x664 instead of 8r664. Currently, there is no syntax for binary literals, and the syntax for octal literals is both magical (where else in integer mathematics does a leading zero matter?) and somewhat error prone (int and eval will give different answers for a numeric literal with a leading zero - int ignores the leading zero, eval treats it as signifying that the value is in octal. The charming result is that the following statement fails: assert int('0123') == 0123).

That's just a misunderstanding on your part. The default radix is
10, not DWIM. 0 signifies that behavior::

assert int('0123', 0) == 0123 assert int('0x123', 0) == 0x123

-bob

More information about the Python-Dev mailing list