On Wed, 25 Jul 2007 10:22:46 -0700, [EMAIL PROTECTED] wrote: > On Jul 24, 6:08 pm, Steven D'Aprano > <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
