Proposal: Decimal literals in Python.

Tim Roberts timr at probo.com
Sun Oct 28 19:22:54 EDT 2007


MRAB <google at mrabarnett.plus.com> wrote:

>On Oct 27, 12:12 am, Ben Finney <bignose+hates-s... at benfinney.id.au>
>wrote:
>> Matimus <mccre... at gmail.com> writes:
>> > The trailing L [for 'long' literals] is going away in Python 3.0.
>>
>> Yes. On the other hand, we are gaining '0bNNNN' for binary literals,
>> to go along with '0oNNNN' for octal and '0xNNNN' for hexadecimal.
>>
>> So, the original poster might get further by proposing an '0dNNN.NNN'
>> syntax for 'decimal.Decimal' literals. At least the syntax would be
>> consistent and wouldn't add a new punctuation character to the
>> language...
>>
>[snip]
>Some languages have or permit 0qNNNN or 0QNNNN for octal to reduce the
>chance of confusion of 'O' (oh) with '0' (zero) in uppercase, eg.
>0Q123 is clearer than 0O123 (0 oh 123), although lowercase is better,
>eg. 0q123 or 0o123.

My favorite notation for this comes from Ada, which allows arbitrary bases
from 2 to 16, and allows for underscores within numeric literals:

  x23_bin : constant :=  2#0001_0111#;
  x23_oct : constant :=  8#27#;
  x23_dec : constant := 10#23#;
  x23_hex : constant := 16#17#;

The opportunities for obfuscated coding by writing all constants in base 7
boggle the mind.

I'm not convinced you need delimiters on both ends; I think 16'fffe_3777
would be just as good.

Although, now that I think about the original thread, this doesn't have a
neat solution for the decimal problem...
-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.



More information about the Python-list mailing list