[Python-Dev] Octal literals

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