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)"
>> <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
