On Jul 26, 1:24 am, Ben Finney <[EMAIL PROTECTED]>
wrote:
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> > On Jul 25, 9:04?pm, Steven D'Aprano
> > <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
