From D

[Ben Finney]

"mensanator at aol.com" <mensanator at aol.com> writes:

> So, just as
> 
>     >>> int('123' '456')
>     123456
> 
> is not an error, the proposal is that
> 
>     >>> a = 123 456
>     SyntaxError: invalid syntax
> 
> will not be an error either.

More directly: Just as these three statements create the same literal
value:

    >>> 'abc' 'def'
    'abcdef'
    >>> 'ab' 'cd' 'ef'
    'abcdef'
    >>> 'abcdef'
    'abcdef'

the proposal is that these three statements create the same literal
value:

    >>> 12 345.678 90
    12345.67890
    >>> 12 3456.78 90
    12345.67890
    >>> 12345.67890
    12345.67890

and not be a syntax error.

> Yet,
> 
>     >>> a = int('123 456')
>     Traceback (most recent call last):
>       File "<pyshell#7>", line 1, in <module>
>         a = int('123 456')
>     ValueError: invalid literal for int() with base 10: '123 456'
> 
> will still be an error.

Since that value, '123 456', is one that is rejected by the 'int'
constructor. Nothing to do with this proposal.

> Just trying to be clear on this. Wouldn't want that syntax behavior
> to carry over into run-time.

The distinction you need to be clear on is between the Python syntax
for writing literal values in code (which is proposed to change by
this), and the behaviour of operations on arbitrary values at runtime
(which is outside the scope of this proposal).

-- 
 \        "I bought a dog the other day. I named him Stay. It's fun to |
  `\     call him. 'Come here, Stay! Come here, Stay!' He went insane. |
_o__)      Now he just ignores me and keeps typing."  -- Steven Wright |
Ben Finney