From D

[mensanator at aol.com]

On Jul 26, 1:24 am, Ben Finney <bignose+hates-s... at benfinney.id.au>
wrote:
> "mensana... at aol.com" <mensana... at aol.com> writes:
> > On Jul 25, 9:04?pm, Steven D'Aprano
> > <st... at REMOVE.THIS.cybersource.com.au> wrote:
> > Why does it make no sense? Have you never had to scrape a web page
> > or read a CSV file?
>
> Again, unrelated to the way the Python compiler syntactically treats
> the source code.

That's what I was enquiring about.

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.

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. Just trying to be clear on this. Wouldn't
want that syntax behavior to carry over into run-time.

>
> > So this proposal would only apply to string literals at compile
> > time, not running programs?
>
> Exactly the same way that it works for string literals in source code:
> once the source code is compiled, the literal is indistinguishable
> from the same value written a different way.
>
> > And I want the same error to occur if my CSV parser tries to convert
> > '123 456' into a single number.  I don't want it to assume the
> > number is '123456'.
>
> Once again, this is a discussion about Python syntax, not the
> behaviour of the csv module.

Who said I was using the csv module?

>
> --
>  \            "I always had a repulsive need to be something more than |
>   `\                                           human."  -- David Bowie |
> _o__)                                                                  |
> Ben Finney