Numeric literals in other than base 10 - was Annoying octal notation

[J. Cliff Dyer]

I had an objection to using spaces in numeric literals last time around
and it still stands, and it still stands in the new one.

What happens if you use a literal like 0x10f 304?  Is 304 treated as
decimal or hexadecimal?  It's not clear how you would begin to combine
it   The way string concatenation works, it takes two independent string
literals, and combines them.  If you specify r'\n' 'abc\n', the first
half is treated independently as a raw string, and the second half is
treated as a normal string.  The result is '\\nabc\n'.

With numeric literals, this behavior doesn't even make sense.  How do
you concatenate hex 10f with decimal 304?  I suppose you could multiply
0x10f by 1000, and add them, but this probably wouldn't fit any
practical usecase.  

Alternatively, you could raise an exception, and require the user to use
numeric literals of the same type, like 0x10f 0x304, but then you lose
any readability benefit you might have gained by dropping the _ to begin
with.  

If, on the other hand, you want to combine the tokens before processing
their independent meanings, which makes the most intuitive sense, well,
in that case we're no longer talking about an operation analogous to
string contcatenation.  We're talking about integers no longer being
simple tokens that can be assigned a value.  I'm not familiar with the
code that makes all this happen in C Python (or any other implementation
for that matter), but it seems like it extends the complexity of the
parser unnecessarily. 

I'm concerned that the benefit in readability will be outweighed by the
burden it places on the parser, and the cognitive burden on the
programmer of knowing what to expect when using non-decimal numeric
literals.  For that reason, I'm a -1 on using a space in numeric
literals, but +1 on using some other separator, and an _, in spite of
its slight awkwardness in typing, seems like a good idea.

If someone with a solid understanding of the python parser could chime
in that this wouldn't cause as much friction as I think, and explain a
clean, elegant implementation for this, many of my concerns would be
alleviated, and I would change my -1 to a -0.

Cheers,
Cliff


On Mon, 2009-08-24 at 00:01 +1000, Ben Finney wrote:
> garabik-news-2005-05 at kassiopeia.juls.savba.sk writes:

> > Why not just use the space? 123 000 looks better than 123_000, and is
> > not syntactically ambiguous (at least in python). And as it already
> > works for string literals, it could be applied to numbers, too…
> 
> +1 to all this. I think this discussion was had many months ago, but
> can't recall how it ended back then.
> 
> -- 
>  \              “Only the educated are free.” —Epictetus, _Discourses_ |
>   `\                                                                   |
> _o__)                                                                  |
> Ben Finney