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

[Ian Kelly]

On Thu, Mar 26, 2015 at 12:54 PM, Thomas 'PointedEars' Lahn
<PointedEars at web.de> wrote:
> Ian Kelly wrote:
>> What I mean is that if you construct a parse tree of "foo" "bar" using
>> that grammar, it looks like this:
>>
>>      expr
>>        |
>>     STRING+
>>      /   \
>> STRING  STRING
>> […]
>>
>> There is only one expr node, and it contains both STRING tokens.
>
> Prove it.

I'm not going to expend the effort that would be required to go
through the entire Python grammar step-by-step and exhaustively prove
that "foo" "bar" can unambiguously only be produced as a single expr.
If you believe otherwise, show a parse tree that parses these as
separate expressions.

> But be warned: Neither would prove that a string literal is not an
> expression.

I've not claimed that a string literal is not an expression. My claim
is that a literal consisting of the implicit concatenation of more
than one string token is can only be parsed as one expression, not
several. Parsing "foo" "bar"

>  Because you did not consider the most simple variant of an AST
> (or subtree) according to this grammar:
>
>     expr
>      |
>    STRING

Of course I did. This is again *exactly* what I was talking about in
reference to parsing the individual strings in isolation.

> Again, “STRING+” does _not_ mean “STRING STRING STRING*”; it means “STRING
> STRING*”.  The second and following STRINGs are *optional*.

Please stop speaking down to me. I'm quite familiar with basic concepts of EBNF.

>>> […] 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*.
>>
>> It means one or more *tokens*, not one or more literals.
>
> Utter nonsense.  Have you ever written a parser?  (I have.)

Yes.

>  A literal *is*
> a token.  Whether two consecutive tokens end up as the same *node* in an AST
> is a *different* issue (that, again, was _not_ debated).

I was going to respond with a comment about how literals are a type of
expression, not token, using a literal tuple as an example of a
literal that is not a token. Then I checked the docs and noticed that
the language reference actually shies away from calling this a literal
and uses the phrase "container display" instead. Browsing through the
specifications of a few other languages (e.g. ECMAscript, which has
so-called "object literals"), they all seem to share the pattern of
using "literal" strictly to mean a type of token in their specs,
despite the word taking on a much broader meaning when writing
informally. So I'll have to concede that point as well.