From D

[Steven D'Aprano]

On Wed, 25 Jul 2007 10:22:46 -0700, mensanator at aol.com wrote:

> On Jul 24, 6:08 pm, Steven D'Aprano
> <st... at REMOVE.THIS.cybersource.com.au> wrote:
>> On Tue, 24 Jul 2007 20:09:00 +0200, Bjoern Schliessmann wrote:
>> > Stargaming wrote:
>> >> On Tue, 24 Jul 2007 03:19:53 -0700, bearophileHUGS wrote:
>>
>> >>> While in a syntax like:
>> >>> for i in xrange(1_000_000):
>> >>> my eyes help me group them at once.
>>
>> >> Sounds like a good thing to be but the arbitrary positioning
>> >> doesnt make any sense.
>>
>> > Checking underscore positions would only add complexity. Why not
>> > just ignore them, no matter where they are?
>>
>> Underscores in numerics are UGLY. Why not take a leaf out of implicit
>> string concatenation and allow numeric literals to implicitly concatenate?
>>
>> Python already does:
>> "hello-" "world" => "hello-world"
>>
>> Propose:
>> 123 456 789 => 123456789
>> 123.456 789 => 123.456789
> 
> So, spaces will no longer be delimiters? Won't that cause
> much wailing and gnashing of teeth?


Did you miss the bit where Python ALREADY does this for strings?

Yes, whitespace will still delimit tokens. No, it won't be a problem,
because two int tokens can be "concatenated" to make a single int token,
exactly as happens for strings.

(I say "no problem", but of course I don't know how much _actual_ coding
effort will be needed to Make This Work. It might be a little, it might be
a lot.)

Currently, 234 567 is a syntax error in Python, so there are no problems
with backward compatibility or breaking code that relies on the meaning of
whitespace between two ints.


-- 
Steven