A simple single line, triple-quoted comment is giving syntax error. Why?

Thomas 'PointedEars' Lahn PointedEars at web.de
Thu Mar 26 12:45:48 EDT 2015


Ian Kelly wrote:

> […] Thomas 'PointedEars' Lahn […] wrote:
>> Chris Angelico wrote:
>>> […] Thomas 'PointedEars' Lahn […] 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+.

How did you get that idea?  STRING+ means one or more consecutive STRING 
tokens (ignoring whitespace in-between), which means one or more consecutive 
string literals.  A (single) string literal definitely is an expression as 
it can be produced with the “expr” goal symbol of the Python grammar (given 
there in a flavor of EBNF).

> By the same token, a STRING+ is a single string literal, not
> an aggregate of several.

No, in the used flavour of EBNF the unquoted “+” following a goal symbol 
clearly means the occurrence of *at least one* of the immediately preceding 
symbol, meaning either one *or more than one*.

<http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form> pp.

> 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.

What do you mean?

ast.literal_eval() sees a single string value resulting from the evaluation 
of one string literal, by the Python compiler, that contains the 
representation of two consecutive string literals:

  '"foo" "bar"'

It then does exactly what the Python compiler would do in such a case: parse 
this as if it were one string literal (the “implicit concatenation” I am 
talking about).

  "foo" "bar" ≡ "foobar"

This was not debated.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.



More information about the Python-list mailing list