On Wed, Mar 25, 2015 at 10:35 PM, Thomas 'PointedEars' Lahn
<pointede...@web.de> wrote:
> Chris Angelico wrote:
>
>> On Sun, Mar 22, 2015 at 2:49 PM, Thomas 'PointedEars' Lahn
>> <pointede...@web.de> wrote:
>>>> Implicit concatenation is part of the syntax, not part of the expression
>>>> evaluator.
>>> Reads like nonsense to me.
>>
>> What do you mean?
>
> As I showed, string literals and consecutive tokens of string literals
> (“STRING+”) so as to do implicit concatenation *are* expressions of the
> Python grammar. Expressions are *part of* the syntax of a programming
> language.
>
> Perhaps you mean that the time when implicit concatenation is evaluated
> (compile time) differs from the time when other expressions are evaluated
> (runtime). But a) whether that is true depends on the implementation and
> b) there can be no doubt that either expression needs to be evaluated. So
> whatever you mean by “expression evaluator” has to be able to do those
> things.
>
> Which makes the statement above read like nonsense to me.
What the grammar that you quoted from shows is that STRING+ is an
expression. The individual STRINGs of a STRING+ are not expressions,
except to the extent that they can be parsed in isolation as a
STRING+. By the same token, a STRING+ is a single string literal, not
an aggregate of several.
Ancillary data point:
>>> help(ast.literal_eval)
Safely evaluate an expression node or a string containing a Python
expression. The string or node provided may only consist of the following
Python literal structures: strings, bytes, numbers, tuples, lists, dicts,
sets, booleans, and None.
>>> ast.literal_eval('"foo" "bar"')
'foobar'
So the ast.literal_eval also treats this as one literal expression.
--
https://mail.python.org/mailman/listinfo/python-list
