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

[Ian Kelly]

On Fri, Apr 3, 2015 at 1:13 AM, Marko Rauhamaa  wrote:
>  2. The counterexample "abc" "def" *does* demonstrate that expressions
> can at times follow each other immediately. It is a nice point even
> if not all that consequential.
>
> Somewhat analogously:
>  * ord  is an expression
>  * ("a")  is an expression
>  * ord("a")  is an expression

I'm tired of this also, so I'll make this response short. By analogy to English:

* "far" is an English adverb.
* "lands" is an English noun.
* "far lands" is an English noun phrase.

* Therefore, a noun phrase in English can consist of an adverb
immediately followed by a noun that is modified by the adverb

The fallacy here is that the "far" in "far lands" is used as an
adjective, not an adverb. I think that the same fallacy applies to the
Python expressions above. If you disagree, that's fine; I'll let it
go.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Marko Rauhamaa]

Chris Angelico :

> I know that it started in response to my statement that string literal
> concatenation wasn't an expression as such, but I have no idea what
> either side of the current debate is, nor how it affects my
> statement's validity.

This is what I have gathered:

 - A Python expression cannot directly follow another expression. A
   connector is required by the syntax.

 - That's untrue:
* "abc"  is an expression
* "def"  is an expression
* "abc" "def"  is an expression
   QED

 - Merging "abc" "def" is a matter of lexical analysis.

 - No, it's right there in the syntax definition.

 - Well, ok, however, the parse tree for "abc" "def" is not

   expr:
 expr:
   atom:
 string: "abc"
 expr:
   atom:
 string: "def"

   Rather, the correct parse tree is:

   expr:
 expr:
   atom:
 string: "abc"
 string: "def"

   Thus, a Python expression still is not directly following another
   expression.


My own take: all sides are correct. Thomas is most correct and is being
obnoxious about it.

 1. A lexical analyzer *could* take care of concatenating string
literals. It would have to be smart enough to handle intervening
comments. On the other hand, the lexical analyzer is just a part of
the parser; the line between them often is blurred.

 2. The counterexample "abc" "def" *does* demonstrate that expressions
can at times follow each other immediately. It is a nice point even
if not all that consequential.

Somewhat analogously:
 * ord  is an expression
 * ("a")  is an expression
 * ord("a")  is an expression

 3. Arguing about definitions is silly. Is 0 a natural number? Is 1 a
prime number?


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Ian Kelly]

On Thu, Apr 2, 2015 at 11:40 PM, Steven D'Aprano
 wrote:
> This sterile, pointless arguing about the minutia of pedantic definitions is
> not even close to useful. Honestly Thomas, Ian, nobody cares any more. If I
> were a betting man, I'd bet that neither of you can describe, in one
> sentence, what is the actual disagreement between the two of you, let alone
> why it matters for Python programming.

Oh, either of us *could* describe it in one sentence; it's just that
our descriptions of how we disagree would not agree. ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Fri, Apr 3, 2015 at 4:40 PM, Steven D'Aprano
 wrote:
> This sterile, pointless arguing about the minutia of pedantic definitions is
> not even close to useful. Honestly Thomas, Ian, nobody cares any more. If I
> were a betting man, I'd bet that neither of you can describe, in one
> sentence, what is the actual disagreement between the two of you, let alone
> why it matters for Python programming.

I know that it started in response to my statement that string literal
concatenation wasn't an expression as such, but I have no idea what
either side of the current debate is, nor how it affects my
statement's validity. I _had_ hoped it would reach some sort of
conclusion - I may be right, I may be wrong, but it'd be nice to know
which. So far... no idea.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Friday 03 April 2015 08:31, Thomas 'PointedEars' Lahn wrote:

> I am sorry that you cannot see that your argument is strewn with gaping
> defects in logic, but I think I will stop trying to convince you of that
> now.

I'm sorry, I've been away for four days and have lost track of this thread. 
Have you reached an agreement about the number of angels which dance on the 
head of a pin yet, or will this argument continue for another week?

This sterile, pointless arguing about the minutia of pedantic definitions is 
not even close to useful. Honestly Thomas, Ian, nobody cares any more. If I 
were a betting man, I'd bet that neither of you can describe, in one 
sentence, what is the actual disagreement between the two of you, let alone 
why it matters for Python programming.


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Ian Kelly]

On Thu, Apr 2, 2015 at 3:31 PM, Thomas 'PointedEars' Lahn
 wrote:
> Ian Kelly wrote:
>
>> […] Thomas 'PointedEars' Lahn […] wrote:
>>> Ian Kelly wrote:
 Within a grammar, the question of "is an X a Y" is nonsensical in
 isolation. It can only be answered in relation to a parse tree.
 Consider the simple grammar:

 S -> A | B
 A -> x
 B -> x

 Is x an A? It depends.
>>>
>>> No, by the definition 2 below, that we all accepted implicitly up to this
>>> point, x is *definitely* an A.
>>
>> What gives you the impression that I ever accepted it?
>
> ,-
> |
> | What the grammar that you quoted from shows is that STRING+ is an
> | expression.
>
> There is *no way* for you to make that statement if you did not accept
> definition (2).

Actually, there is a very simple way: I was being sloppily imprecise
when I wrote that.  First, I was speaking only in reference to the
class of parse trees with more than one STRING, as that was the topic
under discussion. I should have been clearer about that. Second, I
never should have used the term "STRING+" there (or anywhere else in
this discussion), as that merely clouded the point I was trying to
offer. What I *meant* was that the complete sequence of produced
STRINGs -- as opposed to any individual STRING -- is an expression,
and I inappropriately used "STRING+" to denote that. (Maybe that is
the point you were trying to make when you were talking about EBNF
before.)

>> This question of whether "x is an A" is informal and not a topic of formal
>> language theory so far as I'm aware. Can you cite some source for it?
>
> No, because I was formalizing the ad-hoc definition by Chris Angelico in
> .

That URI is not useful to me as I don't use a newsreader. Is that the
message dated Sun, 22 Mar 2015 14:36:48 +1100? I don't see any
suggestion of this definition in that post.

t>>> Now, according to these definitions, in the offered grammar x is *both*
>>> an A and a B.  Because what matters is _not_ the practical result of
>>> production chains (the actual parse tree), but the certainty of the
>>> theoretical possibility of it.
>>
>> This strikes me as being a lot like arguing, "some kites are toys, and
>> some kites are birds; therefore, all kites are both toys and birds."
>
> False analogy again.  We are discussing *in theory* a *formal* grammar.  Its
> goal symbols have *no meaning* except what can be produced from them.

We're discussing a formal grammar as if it described a classification
hierarchy, which gives meaning to statements like "A STRING is an
expr". Otherwise, that statement is meaningless and can be neither
true nor false. So I think that the analogy between one such hierarchy
and another is apt.

>> You're really going to make me spell it out, aren't you? Fine, here you
>> go.
>>
>> single_input -> […] -> expr -> […] -> atom -> STRING STRING
>>
>> Note: the derivation contains exactly one expr node, which indirectly
>> produces both STRINGs. Neither STRING in this derivation is
>> individually produced from the expr.
>
> So you have proven that which nobody ever doubted nor requested, but I
> pointed out already.

As I tried to point out several posts back when I suggested that we
were in agreement, and which you flatly denied.

> What you have still not proven is what you claimed:
> the parse tree.

Because you misunderstood my claim.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[sohcahtoa82]

On Thursday, April 2, 2015 at 2:33:17 PM UTC-7, Thomas 'PointedEars' Lahn wrote:
> Ian Kelly wrote:
> 
> > […] Thomas 'PointedEars' Lahn […] wrote:
> >> Ian Kelly wrote:
> >>> Within a grammar, the question of "is an X a Y" is nonsensical in
> >>> isolation. It can only be answered in relation to a parse tree.
> >>> Consider the simple grammar:
> >>>
> >>> S -> A | B
> >>> A -> x
> >>> B -> x
> >>>
> >>> Is x an A? It depends.
> >>
> >> No, by the definition 2 below, that we all accepted implicitly up to this
> >> point, x is *definitely* an A.
> > 
> > What gives you the impression that I ever accepted it?
> 
> ,-
> | 
> | What the grammar that you quoted from shows is that STRING+ is an
> | expression.
> 
> There is *no way* for you to make that statement if you did not accept 
> definition (2).
> 
> >> (2) Let the statement “x is an A” be true if x can be produced in a
> >> production chain starting with or including the non-terminal A
> >> left-hand side –
> >>
> >>   x ∈ A ↔ ∃A (… ⇒ A ⇒ … ⇒ x).
> > 
> > Sorry, but this definition just seems entirely arbitrary to me.
> 
> It is just the formalization of the definition that we all have agreed to, 
> including you.
> 
> > Mathematically, it looks nonsensical; A is a symbol, not a set.
> 
> “A” is the goal symbol of a production, so it can be interpreted as the 
> superset of all set of terminals that can be produced from it, through the 
> goal symbols that can be produced from it.  And all of us implicitly did 
> that when we said “STRING(+) (literals) is/are (not) (an) expression(s)”.
> 
> > This question of whether "x is an A" is informal and not a topic of formal
> > language theory so far as I'm aware. Can you cite some source for it?
> 
> No, because I was formalizing the ad-hoc definition by Chris Angelico in 
> .
> 
> >> Now, according to these definitions, in the offered grammar x is *both*
> >> an A and a B.  Because what matters is _not_ the practical result of
> >> production chains (the actual parse tree), but the certainty of the
> >> theoretical possibility of it.
> > 
> > This strikes me as being a lot like arguing, "some kites are toys, and
> > some kites are birds; therefore, all kites are both toys and birds."
> 
> False analogy again.  We are discussing *in theory* a *formal* grammar.  Its 
> goal symbols have *no meaning* except what can be produced from them.
> 
> > As noted above, the inaccuracy that Gregory pointed out has no bearing
> > on my argument.
> 
> But it does.
> 
> > You're really going to make me spell it out, aren't you? Fine, here you
> > go.
> > 
> > single_input -> […] -> expr -> […] -> atom -> STRING STRING
> > 
> > Note: the derivation contains exactly one expr node, which indirectly
> > produces both STRINGs. Neither STRING in this derivation is
> > individually produced from the expr.
> 
> So you have proven that which nobody ever doubted nor requested, but I 
> pointed out already.  What you have still not proven is what you claimed: 
> the parse tree.
> 
> I am sorry that you cannot see that your argument is strewn with gaping 
> defects in logic, but I think I will stop trying to convince you of that 
> now.
> 
> -- 
> PointedEars
> 
> Twitter: @PointedEars2
> Please do not cc me. / Bitte keine Kopien per E-Mail.

*sigh*

https://xkcd.com/386/
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

Ian Kelly wrote:

> […] Thomas 'PointedEars' Lahn […] wrote:
>> Ian Kelly wrote:
>>> Within a grammar, the question of "is an X a Y" is nonsensical in
>>> isolation. It can only be answered in relation to a parse tree.
>>> Consider the simple grammar:
>>>
>>> S -> A | B
>>> A -> x
>>> B -> x
>>>
>>> Is x an A? It depends.
>>
>> No, by the definition 2 below, that we all accepted implicitly up to this
>> point, x is *definitely* an A.
> 
> What gives you the impression that I ever accepted it?

,-
| 
| What the grammar that you quoted from shows is that STRING+ is an
| expression.

There is *no way* for you to make that statement if you did not accept 
definition (2).

>> (2) Let the statement “x is an A” be true if x can be produced in a
>> production chain starting with or including the non-terminal A
>> left-hand side –
>>
>>   x ∈ A ↔ ∃A (… ⇒ A ⇒ … ⇒ x).
> 
> Sorry, but this definition just seems entirely arbitrary to me.

It is just the formalization of the definition that we all have agreed to, 
including you.

> Mathematically, it looks nonsensical; A is a symbol, not a set.

“A” is the goal symbol of a production, so it can be interpreted as the 
superset of all set of terminals that can be produced from it, through the 
goal symbols that can be produced from it.  And all of us implicitly did 
that when we said “STRING(+) (literals) is/are (not) (an) expression(s)”.

> This question of whether "x is an A" is informal and not a topic of formal
> language theory so far as I'm aware. Can you cite some source for it?

No, because I was formalizing the ad-hoc definition by Chris Angelico in 
.

>> Now, according to these definitions, in the offered grammar x is *both*
>> an A and a B.  Because what matters is _not_ the practical result of
>> production chains (the actual parse tree), but the certainty of the
>> theoretical possibility of it.
> 
> This strikes me as being a lot like arguing, "some kites are toys, and
> some kites are birds; therefore, all kites are both toys and birds."

False analogy again.  We are discussing *in theory* a *formal* grammar.  Its 
goal symbols have *no meaning* except what can be produced from them.

> As noted above, the inaccuracy that Gregory pointed out has no bearing
> on my argument.

But it does.

> You're really going to make me spell it out, aren't you? Fine, here you
> go.
> 
> single_input -> […] -> expr -> […] -> atom -> STRING STRING
> 
> Note: the derivation contains exactly one expr node, which indirectly
> produces both STRINGs. Neither STRING in this derivation is
> individually produced from the expr.

So you have proven that which nobody ever doubted nor requested, but I 
pointed out already.  What you have still not proven is what you claimed: 
the parse tree.

I am sorry that you cannot see that your argument is strewn with gaping 
defects in logic, but I think I will stop trying to convince you of that 
now.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Ian Kelly]

On Mar 31, 2015 5:16 PM,  wrote:
> Holy hell, dude, you've been arguing about this for nearly two weeks now.
>
> Let it go.

That's rather an exaggeration. I've made seven posts to this thread up
until now, the first of which was six days ago, not two weeks. I don't
think that's excessive.

I suggested dropping it a couple of posts back, but Thomas seemed
interested in continuing to seek clarity, which I have no objection to.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Wed, Apr 1, 2015 at 10:10 AM,   wrote:
> Holy hell, dude, you've been arguing about this for nearly two weeks now.
>
> Let it go.

Not sure you understand the nature of language debates. They can't
hold it back any more!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[sohcahtoa82]

On Tuesday, March 31, 2015 at 12:24:53 AM UTC-7, Ian wrote:
> On Sun, Mar 29, 2015 at 4:41 AM, Thomas 'PointedEars' Lahn
>  wrote:
> > Ian Kelly wrote:
> >
> >> […] Thomas 'PointedEars' Lahn […] wrote:
> >>> Ian Kelly wrote:
> >> Why should the burden of proof be on me in the first place?
> >
> > Because *you* made the claim that “STRING+” could be part of an AST in this
> > way.
> 
> Okay, I didn't understand before that this was the part that you were
> objecting to. I had written "There is only one expr node, and it
> contains both STRING tokens", to which you replied "Prove it." I did
> not intend to imply anything at all by the inclusion of STRING+ in the
> tree. That pseudo-tree was hastily sketched out, and as both you and
> Gregory have pointed out, STRING+ is not a symbol of the grammar and
> should not have been included as a node. None of this has any bearing
> on what I was trying to demonstrate with that tree.
> 
> >> Within a grammar, the question of "is an X a Y" is nonsensical in
> >> isolation. It can only be answered in relation to a parse tree.
> >> Consider the simple grammar:
> >>
> >> S -> A | B
> >> A -> x
> >> B -> x
> >>
> >> Is x an A? It depends.
> >
> > No, by the definition 2 below, that we all accepted implicitly up to this
> > point, x is *definitely* an A.
> 
> What gives you the impression that I ever accepted it?
> 
> >> If the tree that generates the x produces it from an A node, then yes.
> >> Otherwise, no.
> >
> > Fallacy.
> >
> > First, two definitions, so that we are clear what we are talking about:
> >
> > (1) Let a *production chain* be the repeated application of the production
> > rules of a formal grammar such that
> >
> >   C ⇒ D ⇒ x
> >
> > is a production chain if there are production rules
> >
> >   C → D
> >   D → x.
> >
> > [Note the difference between “⇒” and “→”.]
> 
> Sure.
> 
> > (2) Let the statement “x is an A” be true if x can be produced in a
> > production chain starting with or including the non-terminal A
> > left-hand side –
> >
> >   x ∈ A ↔ ∃A (… ⇒ A ⇒ … ⇒ x).
> 
> Sorry, but this definition just seems entirely arbitrary to me.
> Mathematically, it looks nonsensical; A is a symbol, not a set. This
> question of whether "x is an A" is informal and not a topic of formal
> language theory so far as I'm aware. Can you cite some source for it?
> 
> > Now, according to these definitions, in the offered grammar x is *both* an A
> > and a B.  Because what matters is _not_ the practical result of production
> > chains (the actual parse tree), but the certainty of the theoretical
> > possibility of it.
> 
> This strikes me as being a lot like arguing, "some kites are toys, and
> some kites are birds; therefore, all kites are both toys and birds."
> 
> >> So when I write that the "foo" in "foo" "bar" is not an expression, I
> >> am only speaking in relation to the parse tree that generates "foo"
> >> "bar".
> >
> > But it has been indicated by others that the parse tree that you presented
> > is wrong, based on a misconception about the syntax of the formal grammar,
> > and you have not yet substantiated your claim that it is correct.
> 
> As noted above, the inaccuracy that Gregory pointed out has no bearing
> on my argument.
> 
> You're really going to make me spell it out, aren't you? Fine, here you go.
> 
> single_input -> simple_stmt -> expr_stmt -> testlist_star_expr -> test
> -> or_test -> and_test -> not_test -> comparison -> expr -> xor_expr
> -> and_expr -> shift_expr -> arith_expr -> term -> factor -> power ->
> atom -> STRING STRING
> 
> Note: the derivation contains exactly one expr node, which indirectly
> produces both STRINGs. Neither STRING in this derivation is
> individually produced from the expr.
> 
> >> I don't know what you mean by a "backdoor".
> >
> > Appending a statement that is contradictory to what was stated just before,
> > or at least ambiguous, so that the possibility arises for one to say “I did
> > not mean that” when that/a contradiction to the former statement is pointed
> > out later.
> 
> The purpose was not to make the possibility arise to say that. The
> purpose was to point out the discontinuity *immediately* so that it
> would be already addressed and not *need* to be pointed out later
> (although we can see how well that turned out).
> 
> I have to say that I find it highly surprising that you find this
> construction objectionable. Would you still consider it
> "contradictory" if I had phrased it equivalently as a logical "or"
> rather than using the word "except"?
> 
> >> The purpose of that parenthetical was to explicitly acknowledge that the
> >> single STRING could be viewed as an expression when taken out of context,
> >
> > Yes, your fallacy is mainly based on ignoring the context.  Context is
> > important; you cannot just ignore it and still make correct arguments.
> 
> Funny, I thought that was my line. This whole argument came about
> because you seem to be stubbo

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

[Jean-Michel Pichavant]

- Original Message -
> From: "Terry Reedy" 
> To: python-list@python.org
> Sent: Wednesday, 18 March, 2015 10:47:40 PM
> Subject: Re: A simple single line, triple-quoted comment is giving syntax 
> error. Why?
> 
> On 3/18/2015 3:53 PM, Thomas 'PointedEars' Lahn wrote:
> 
> > I must strongly object and recommend against getting accustomed to
> > the
> > suggested use of multi-line string literals.
> 
> I agree.

I remember loosing a lot of time finding a bug that can be summarized like this 
(immagine a much larger list where the temptation of commenting a block is 
high):

a =  [  '1',
'''shorten the list to speedup tests
'2',
'3',
'''
'4',
]


print a
>>> ['1', "shorten the list to speedup tests\n\t\t'2',\n\t\t'3',\n4"]

JM


-- IMPORTANT NOTICE: 

The contents of this email and any attachments are confidential and may also be 
privileged. If you are not the intended recipient, please notify the sender 
immediately and do not disclose the contents to any other person, use it for 
any purpose, or store or copy the information in any medium. Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Ian Kelly]

On Sun, Mar 29, 2015 at 4:41 AM, Thomas 'PointedEars' Lahn
 wrote:
> Ian Kelly wrote:
>
>> […] Thomas 'PointedEars' Lahn […] wrote:
>>> Ian Kelly wrote:
>> Why should the burden of proof be on me in the first place?
>
> Because *you* made the claim that “STRING+” could be part of an AST in this
> way.

Okay, I didn't understand before that this was the part that you were
objecting to. I had written "There is only one expr node, and it
contains both STRING tokens", to which you replied "Prove it." I did
not intend to imply anything at all by the inclusion of STRING+ in the
tree. That pseudo-tree was hastily sketched out, and as both you and
Gregory have pointed out, STRING+ is not a symbol of the grammar and
should not have been included as a node. None of this has any bearing
on what I was trying to demonstrate with that tree.

>> Within a grammar, the question of "is an X a Y" is nonsensical in
>> isolation. It can only be answered in relation to a parse tree.
>> Consider the simple grammar:
>>
>> S -> A | B
>> A -> x
>> B -> x
>>
>> Is x an A? It depends.
>
> No, by the definition 2 below, that we all accepted implicitly up to this
> point, x is *definitely* an A.

What gives you the impression that I ever accepted it?

>> If the tree that generates the x produces it from an A node, then yes.
>> Otherwise, no.
>
> Fallacy.
>
> First, two definitions, so that we are clear what we are talking about:
>
> (1) Let a *production chain* be the repeated application of the production
> rules of a formal grammar such that
>
>   C ⇒ D ⇒ x
>
> is a production chain if there are production rules
>
>   C → D
>   D → x.
>
> [Note the difference between “⇒” and “→”.]

Sure.

> (2) Let the statement “x is an A” be true if x can be produced in a
> production chain starting with or including the non-terminal A
> left-hand side –
>
>   x ∈ A ↔ ∃A (… ⇒ A ⇒ … ⇒ x).

Sorry, but this definition just seems entirely arbitrary to me.
Mathematically, it looks nonsensical; A is a symbol, not a set. This
question of whether "x is an A" is informal and not a topic of formal
language theory so far as I'm aware. Can you cite some source for it?

> Now, according to these definitions, in the offered grammar x is *both* an A
> and a B.  Because what matters is _not_ the practical result of production
> chains (the actual parse tree), but the certainty of the theoretical
> possibility of it.

This strikes me as being a lot like arguing, "some kites are toys, and
some kites are birds; therefore, all kites are both toys and birds."

>> So when I write that the "foo" in "foo" "bar" is not an expression, I
>> am only speaking in relation to the parse tree that generates "foo"
>> "bar".
>
> But it has been indicated by others that the parse tree that you presented
> is wrong, based on a misconception about the syntax of the formal grammar,
> and you have not yet substantiated your claim that it is correct.

As noted above, the inaccuracy that Gregory pointed out has no bearing
on my argument.

You're really going to make me spell it out, aren't you? Fine, here you go.

single_input -> simple_stmt -> expr_stmt -> testlist_star_expr -> test
-> or_test -> and_test -> not_test -> comparison -> expr -> xor_expr
-> and_expr -> shift_expr -> arith_expr -> term -> factor -> power ->
atom -> STRING STRING

Note: the derivation contains exactly one expr node, which indirectly
produces both STRINGs. Neither STRING in this derivation is
individually produced from the expr.

>> I don't know what you mean by a "backdoor".
>
> Appending a statement that is contradictory to what was stated just before,
> or at least ambiguous, so that the possibility arises for one to say “I did
> not mean that” when that/a contradiction to the former statement is pointed
> out later.

The purpose was not to make the possibility arise to say that. The
purpose was to point out the discontinuity *immediately* so that it
would be already addressed and not *need* to be pointed out later
(although we can see how well that turned out).

I have to say that I find it highly surprising that you find this
construction objectionable. Would you still consider it
"contradictory" if I had phrased it equivalently as a logical "or"
rather than using the word "except"?

>> The purpose of that parenthetical was to explicitly acknowledge that the
>> single STRING could be viewed as an expression when taken out of context,
>
> Yes, your fallacy is mainly based on ignoring the context.  Context is
> important; you cannot just ignore it and still make correct arguments.

Funny, I thought that was my line. This whole argument came about
because you seem to be stubbornly insistent on ignoring the context
that I set for my statement, calling it "contradictory" instead.

>> and to disclaim that I was excluding that case from the preceding
>> statement. I still stand by that statement; The "foo" in "foo" "bar" is
>> not an expression in the same sense that the "42" is

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

[Thomas 'PointedEars' Lahn]

Ian Kelly wrote:

> […] Thomas 'PointedEars' Lahn […] wrote:
>> Ian Kelly wrote:
>>> […] Thomas 'PointedEars' Lahn […] 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.
>>
>> And why should you?  That is not what you claimed.
> 
> Of course it is. I claimed that there was only one expr node in the
> parse tree of "foo" "bar".

Which is something else.

> That would require two things: […]

What I asked you would require only a real-life representation of the parse 
tree above.

>>> If you believe otherwise, show a parse tree that parses these as
>>> separate expressions.
>> Fallacies: Straw man, shifting the burden of proof.
> 
> If there is a straw man here, it is only the result of one or both of
> us failing to communicate.

I agree.

> If so, then why did you ask me to prove it?

See above.

> Why should the burden of proof be on me in the first place?

Because *you* made the claim that “STRING+” could be part of an AST in this 
way.

> In any case, it sounds to me like we're probably in agreement at this
> point.

I do not think so.

> Within a grammar, the question of "is an X a Y" is nonsensical in
> isolation. It can only be answered in relation to a parse tree.
> Consider the simple grammar:
> 
> S -> A | B
> A -> x
> B -> x
> 
> Is x an A? It depends.

No, by the definition 2 below, that we all accepted implicitly up to this 
point, x is *definitely* an A.

> If the tree that generates the x produces it from an A node, then yes. 
> Otherwise, no.

Fallacy.

First, two definitions, so that we are clear what we are talking about:

(1) Let a *production chain* be the repeated application of the production   
rules of a formal grammar such that

  C ⇒ D ⇒ x

is a production chain if there are production rules

  C → D
  D → x.

[Note the difference between “⇒” and “→”.]

(2) Let the statement “x is an A” be true if x can be produced in a
production chain starting with or including the non-terminal A
left-hand side –

  x ∈ A ↔ ∃A (… ⇒ A ⇒ … ⇒ x).

Now, according to these definitions, in the offered grammar x is *both* an A 
and a B.  Because what matters is _not_ the practical result of production 
chains (the actual parse tree), but the certainty of the theoretical 
possibility of it.

However, in the interest of disambiguity in their parsers, programming 
languages do not have such a set of production rules in their grammar that 
lead to ambiguous productions.  In particular, you will not find in the 
Python grammar another production rule that leads to “STRING” being 
producable by a production chain not containing “expr”.

So, if we accept these definitions, we can and have to extend the 
classification of STRING( literals) to say that they are “atom”s, 
“arith(metic)_expr”(ession)s (as strange as that may sound), and so on, 
“expr”(ession)s, “comparison”s and so on (as strange as that may sound),
and finally “st(ate)m(en)t”s (this fact started the whole discussion),
and “single_input”s, and not anything else.

> So when I write that the "foo" in "foo" "bar" is not an expression, I
> am only speaking in relation to the parse tree that generates "foo"
> "bar".

But it has been indicated by others that the parse tree that you presented 
is wrong, based on a misconception about the syntax of the formal grammar, 
and you have not yet substantiated your claim that it is correct.

> I am not speaking about the parse tree that generates only
> "foo", because it is irrelevant, even though in that context it would
> be an expression.

Same fallacy as above.

> I don't know what you mean by a "backdoor".

Appending a statement that is contradictory to what was stated just before, 
or at least ambiguous, so that the possibility arises for one to say “I did 
not mean that” when that/a contradiction to the former statement is pointed 
out later.

> The purpose of that parenthetical was to explicitly acknowledge that the 
> single STRING could be viewed as an expression when taken out of context,

Yes, your fallacy is mainly based on ignoring the context.  Context is 
important; you cannot just ignore it and still make correct arguments.

> and to disclaim that I was excluding that case from the preceding 
> statement. I still stand by that statement; The "foo" in "foo" "bar" is 
> not an expression in the same sense that the "42" is not an expression in
> "hucr,.@#%c|42ptqc$".

False analogy.  The “42” in there cannot be produced by “expr” *in that 
context* (it can only b

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

[Ian Kelly]

On Sat, Mar 28, 2015 at 12:20 PM, Thomas 'PointedEars' Lahn
 wrote:
> Ian Kelly wrote:
>
>> […] Thomas 'PointedEars' Lahn […] 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.
>
> And why should you?  That is not what you claimed.

Of course it is. I claimed that there was only one expr node in the
parse tree of "foo" "bar". You asked me to prove it. That would
require two things: first, showing that the complete expansion of the
parse tree above does not include any further expr nodes (which I
contend is obvious enough that it should not need to be explicitly
spelled out in this thread), and second, showing that no other parse
tree will generate "foo" "bar".

>> If you believe otherwise, show a parse tree that parses these as
>> separate expressions.
>
> Fallacies: Straw man, shifting the burden of proof.

If there is a straw man here, it is only the result of one or both of
us failing to communicate. Are you now saying that you agree that
there is only one expr node in the parse of "foo" "bar"? If so, then
why did you ask me to prove it?

Why should the burden of proof be on me in the first place? I made the
request because demonstrating the positive (such a parse tree exists)
would, as usual, be much simpler than proving the negative (no such
parse tree exists).

In any case, it sounds to me like we're probably in agreement at this point.

>>> 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.
>
> Yes, you did.  You debated my statement which says that.  Let me refresh
> your memory.  I said:

You are correct. I was reading "string literal" as STRING+ when I
wrote that. I was perhaps confused because your statement "Neither
would prove that a string literal is not an expression" did not make
sense to me at the time.

Within a grammar, the question of "is an X a Y" is nonsensical in
isolation. It can only be answered in relation to a parse tree.
Consider the simple grammar:

S -> A | B
A -> x
B -> x

Is x an A? It depends. If the tree that generates the x produces it
from an A node, then yes. Otherwise, no.

So when I write that the "foo" in "foo" "bar" is not an expression, I
am only speaking in relation to the parse tree that generates "foo"
"bar". I am not speaking about the parse tree that generates only
"foo", because it is irrelevant, even though in that context it would
be an expression.

> | As I showed, string literals and consecutive tokens of string literals
> | (“STRING+”) so as to do implicit concatenation *are* expressions of the
> | Python grammar.
>
> To which you replied:
>
> | What the grammar that you quoted from shows is that STRING+ is an
> | expression. The individual STRINGs of a STRING+ are not expressions, […]
>  ^^^  ^^^
> You continued with
>
> | except to the extent that they can be parsed in isolation as a STRING+.
>
> but that is nothing more than a backdoor, contradictory to what you said
> before (and, as it has been showed, nonsensical).

I don't know what you mean by a "backdoor". The purpose of that
parenthetical was to explicitly acknowledge that the single STRING
could be viewed as an expression when taken out of context, and to
disclaim that I was excluding that case from the preceding statement.
I still stand by that statement; The "foo" in "foo" "bar" is not an
expression in the same sense that the "42" is not an expression in
"hucr,.@#%c|42ptqc$".

>> 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.
>
> Then you must have fundamentally misunderstood my statement and this whole
> discussion.

Quite possibly. Rereading the thread at the point where I jumped in,
it's not clear to me now what it was in your post that I was
responding to.

>> 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.
>
> Actually, you were arguing against my statement that string literals are
> expressions (that a string literal is an expression).  You claimed, rather
> explicitly, that they were not.  See above.

I have no idea what point you're trying to convey here.

>> I'm quite famili

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

[Tim Roberts]

Aditya Raj Bhatt  wrote:

>On Wednesday, March 18, 2015 at 1:04:39 PM UTC-5, Laurent Pointal wrote:
>> > Can someone also provide a sort of a 'guide' to triple-quoted
>> > comments in general?
>> 
>> A triple ' or " string is a Python string, allowing line-return in
>> string.
>
>What do you mean by line-return in string? Is it newline? Does it mean I
>can write -
>
>'''first part
>second part'''
>
>?
> 
>> If it is in an expression (like a = 5 '''a comment'''), then it must
>> be a 
>> valid expression (and here it is not).
>
>What is not a valid expression here?

Were you ever able to extract the Real Answer to your original question
from the froth that resulted?  Your basic misunderstanding is that the
triple-quote thing is NOT a comment marker.  It is a string literal,
exactly like a single-quoted string, except that it allows embedded
newlines.  So, your statement
a = 5 '''a comment'''
is invalid for exactly the same reason that the statement
a = 5 "a comment"
is invalid.  Neither one of those statement have any comments.

There is a CONVENTION to embed a literal string as the first line in a
function, to allow for automatic documentation.  Whether the literal string
is single-quoted or triple-quoted is irrelevant.  That is, these two things
are equivalent:

def func(a):
"This is a function"
return a*2

def func(a):
"""This is a function"""
return a*2
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

Ian Kelly wrote:

> […] Thomas 'PointedEars' Lahn […] 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.

And why should you?  That is not what you claimed.

> If you believe otherwise, show a parse tree that parses these as
> separate expressions.

Fallacies: Straw man, shifting the burden of proof.

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

Yes, you did.  You debated my statement which says that.  Let me refresh 
your memory.  I said:

| As I showed, string literals and consecutive tokens of string literals 
| (“STRING+”) so as to do implicit concatenation *are* expressions of the 
| Python grammar.

To which you replied:

| What the grammar that you quoted from shows is that STRING+ is an
| expression. The individual STRINGs of a STRING+ are not expressions, […]
 ^^^  ^^^
You continued with

| except to the extent that they can be parsed in isolation as a STRING+.

but that is nothing more than a backdoor, contradictory to what you said 
before (and, as it has been showed, nonsensical).

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

Then you must have fundamentally misunderstood my statement and this whole 
discussion.

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

Actually, you were arguing against my statement that string literals are 
expressions (that a string literal is an expression).  You claimed, rather 
explicitly, that they were not.  See above.

>> 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 am not speaking down to you.  But the fact needed to be emphasized that 
you could not have been reading carefully what I wrote.

> I'm quite familiar with basic concepts of EBNF.

But apparently not logic.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

Gregory Ewing 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
> 
> Not quite -- STRING+ is not a symbol in the grammar, it's
> a shorthand for a combination of symbols. The parse tree
> is actually just
> 
>expr
>/   \
>   STRING  STRING

Or if there is a single STRING,

  expr
   |
  STRING
 
AISB.

>> Not like this:
>> 
>> expr
>>  |
>>STRING+
>> /  \
>>  expr  expr
>>   |  |
>> STRING  STRING
> […]
> 
> To get a parse tree like the above, there would need to be
> a production like this in the grammar:
> 
> expr ::= expr+
> 
> There is no such production, so that parse tree is impossible.
> QED.

Correct.

> What you seem to be doing in your mind

Who is “you” here?  You appear to be confused, probably supported by your 
unconventional quotation style, who made which statement.

> is taking this production:
> 
> expr ::= STRING
> 
> and using it "backwards" to justify expanding any occurrence
> of STRING into expr.

No.

> But grammars don't work that way. You're committing a logical fallacy:
> just because some exprs are STRINGs doesn't mean that all STRINGs are 
> exprs.

The fallacy – a straw man – is yours here.  Nobody – in particular not me – 
claimed that “STRING” can *only* be produced by “expr” in the first place.

Production rules in a formal grammar of the form

  expr   → … | any_goal | …
  any_goal   → … | any_other_goal | …
  any_other_goal → … | STRING+ | …

where the steps in-between are optional, mean *exactly* that (*all*) 
“STRING”s are “expr”s – but that not all “expr”s are “STRING”s.  Because it 
follows from the rules above that these production chains – *but not _only_ 
these* – are possible:

  a) expr ⇒ … ⇒ STRING
  b) expr ⇒ … ⇒ STRING STRING
  c) expr ⇒ … ⇒ STRING STRING STRING

and so on.  The truth of the statement “(All) STRING( literal)s are 
expr(ession)s” is what follows from the possibility of the first production 
chain.  (That does not preclude the possibility that “STRING”s are also an 
element of another set.)

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Marko Rauhamaa]

Steven D'Aprano :

> You're arguing whether or not in the following line of code:
>
> spam = "abcd" "efgh"
> # implicitly concatenated to "abcdefgh" at compile time
>
> the right hand side pair of strings counts as a single token or two? Am I
> right, or am I missing something?
>
> If that's all it is, why don't you just run the tokenizer over it and
> see what it says?

Now, someone *could* write a tokenizer that took care of string
concatenation on the spot--as long as it dealt with comments as well:

   ("abc"
   # hello
"def")

It would be even possible to write a parser that didn't have a separate
lexical analyzer at all.

Arguing about terminology is pretty useless. Both sides in this fight
are correct, namely:

   * string literal concatenation is part of expression syntax

   * what goes on inside an atom stays inside an atom

For example, this expression is illegal:

   "abc" ("def")


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Ian Kelly]

On Thu, Mar 26, 2015 at 5:15 PM, Steven D'Aprano
 wrote:
> Looks to me that the two string literals each get their own token, and are
> concatenated at a later stage of compilation, not during parsing.

Thanks. The dispute was about expressions, though. I think we're all
in agreement that there are two tokens.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Tim Chase]

On 2015-03-27 10:15, Steven D'Aprano wrote:
> If that's all it is, why don't you just run the tokenizer over it
> and see what it says?
> 
> py> from cStringIO import StringIO
> py> code = StringIO('spam = "abcd" "efgh"\n')
> py> import tokenize
> py> for item in tokenize.generate_tokens(code.readline):
> ... print item
> ...
> (1, 'spam', (1, 0), (1, 4), 'spam = "abcd" "efgh"\n')
> (51, '=', (1, 5), (1, 6), 'spam = "abcd" "efgh"\n')
> (3, '"abcd"', (1, 7), (1, 13), 'spam = "abcd" "efgh"\n')
> (3, '"efgh"', (1, 14), (1, 20), 'spam = "abcd" "efgh"\n')
> (4, '\n', (1, 20), (1, 21), 'spam = "abcd" "efgh"\n')
> (0, '', (2, 0), (2, 0), '')
> 
> 
> Looks to me that the two string literals each get their own token,

Nice.  I haven't played with the tokenize module before, but
resolving arguments on comp.lang.python is one of the best possible
uses.

It was interesting to try other feeders to generate_tokens(), my favorite being

>>> import tokenize
>>> i = iter(["spam = 'abc' 'def'"])
>>> for item in tokenize.generate_tokens(lambda: next(i)):
... print(item)
... 
TokenInfo(type=1 (NAME), string='spam', start=(1, 0), end=(1, 4), line="spam = 
'abc' 'def'")
TokenInfo(type=52 (OP), string='=', start=(1, 5), end=(1, 6), line="spam = 
'abc' 'def'")
TokenInfo(type=3 (STRING), string="'abc'", start=(1, 7), end=(1, 12), 
line="spam = 'abc' 'def'")
TokenInfo(type=3 (STRING), string="'def'", start=(1, 13), end=(1, 18), 
line="spam = 'abc' 'def'")
TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')


It's also nice to have the translation from token-type to token-type-name in Py3

-tkc





-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 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
 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.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Fri, 27 Mar 2015 05:56 am, Thomas 'PointedEars' Lahn wrote:
[snip argument]


Hey guys, I'm trying to follow the argument but I must admit you've
completely lost me with the angels-on-the-head-of-a-pin nitpicking about
EBNF. I love a good pedant-brawl as much as you, so let me see if I've got
this straight, correct me if I'm wrong.

You're arguing whether or not in the following line of code:

spam = "abcd" "efgh"
# implicitly concatenated to "abcdefgh" at compile time

the right hand side pair of strings counts as a single token or two? Am I
right, or am I missing something?

If that's all it is, why don't you just run the tokenizer over it and see
what it says?

py> from cStringIO import StringIO
py> code = StringIO('spam = "abcd" "efgh"\n')
py> import tokenize
py> for item in tokenize.generate_tokens(code.readline):
... print item
...
(1, 'spam', (1, 0), (1, 4), 'spam = "abcd" "efgh"\n')
(51, '=', (1, 5), (1, 6), 'spam = "abcd" "efgh"\n')
(3, '"abcd"', (1, 7), (1, 13), 'spam = "abcd" "efgh"\n')
(3, '"efgh"', (1, 14), (1, 20), 'spam = "abcd" "efgh"\n')
(4, '\n', (1, 20), (1, 21), 'spam = "abcd" "efgh"\n')
(0, '', (2, 0), (2, 0), '')


Looks to me that the two string literals each get their own token, and are
concatenated at a later stage of compilation, not during parsing.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Gregory Ewing]

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


Not quite -- STRING+ is not a symbol in the grammar, it's
a shorthand for a combination of symbols. The parse tree
is actually just

  expr
  /   \
 STRING  STRING


Not like this:

expr
 |
   STRING+
/  \
 expr  expr
  |  |
STRING  STRING


That would be

> expr
> /  \
>  expr  expr
>   |  |
> STRING  STRING

Thomas 'PointedEars' Lahn wrote:
> Prove it.

To get a parse tree like the above, there would need to be
a production like this in the grammar:

   expr ::= expr+

There is no such production, so that parse tree is impossible.
QED.

What you seem to be doing in your mind is taking this
production:

   expr ::= STRING

and using it "backwards" to justify expanding any occurrence
of STRING into expr. But grammars don't work that way. You're
committing a logical fallacy: just because some exprs are
STRINGs doesn't mean that all STRINGs are exprs.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

Ian Kelly wrote:

> […] Thomas 'PointedEars' Lahn […] wrote:
>> Ian Kelly wrote:
>>> 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).
> 
> Yes, that's what I was referring to in my parenthetical "except..." above.

Your “except” is contradictory to the rest of what you said, at best.

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

But be warned: Neither would prove that a string literal is not an 
expression.  Because you did not consider the most simple variant of an AST 
(or subtree) according to this grammar:

expr
 |
   STRING

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

>> […] 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.)  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).
 
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

Ian Kelly wrote:

> On Thu, Mar 26, 2015 at 12:29 PM, Ian Kelly  wrote:
>> On Thu, Mar 26, 2015 at 10:45 AM, Thomas 'PointedEars' Lahn
>>> 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*.
>>
>> It means one or more *tokens*, not one or more literals.
> 
> Although reading the documentation, it seems that it also conflates
> string literals with tokens,

There is nothing to conflate here.  String literals *are* tokens.

> so on that I'll have to concede the point.

Too late, the rebuttal is already underway :-p

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Ian Kelly]

On Thu, Mar 26, 2015 at 12:29 PM, Ian Kelly  wrote:
> On Thu, Mar 26, 2015 at 10:45 AM, Thomas 'PointedEars' Lahn
>> 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*.
>
> It means one or more *tokens*, not one or more literals.

Although reading the documentation, it seems that it also conflates
string literals with tokens, so on that I'll have to concede the
point.

https://docs.python.org/3.4/reference/lexical_analysis.html#string-and-bytes-literals
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Ian Kelly]

On Thu, Mar 26, 2015 at 10:45 AM, Thomas 'PointedEars' Lahn
 wrote:
> Ian Kelly wrote:
>> 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).

Yes, that's what I was referring to in my parenthetical "except..." above.

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

Not like this:

expr
 |
   STRING+
/  \
 expr  expr
  |  |
STRING  STRING

There is only one expr node, and it contains both STRING tokens.

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

It means one or more *tokens*, not one or more literals.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

>   multiple-string = STRING *STRING
> […]
> in ABNF.

JFTR: ABNF allows for

  multiple-string = 1*STRING

to be equivalent to the above.

 pp.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

Dave Angel wrote:

[Fixed quotation]

> On 03/26/2015 01:09 AM, Ian Kelly wrote:
> Thomas 'PointedEars' Lahn wrote:
>> > 
>> literal-concatenation>
>>
>> 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.
> 
> That's the way I also read the BNF.

Then I am afraid you need to refresh your knowledge of formal grammars.

> But something I cannot find in that chapter of the reference is the
> definition of STRING+

You *definitely* need to refresh your knowledge of formal grammars.

“STRING+” in this flavor of _E_BNF is – rather obviously – equivalent to

   ::=  *
::= '"' * '"'
  | "'" * "'"
  | '"""' * '"""'
  | "'''" * "'''"

in BNF and

  multiple-string = STRING *STRING
  STRING  = '"' *no-unescaped-doublequote '"'
  / "'" *no-unescaped-singlequote '"'
  / '"""' *no-unescaped-triple-doublequote '"""'
  / "'''" *no-unescaped-triple-singlequote "'''"

in ABNF.  I suspect that in this flavor of EBNF the definition of STRING 
looks similar to the following:

  STRING: ('"' no_unescaped_doublequote* '"'
 | "'" no_unescaped_singlequote* "'"
 | '"""' no_unescaped_triple_doublequote* '"""'
 | "'''" no_unescaped_triple_singlequote* "'''")

Definition of the still undefined goal symbols is left as an exercise to the 
reader.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

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

 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.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Dave Angel]

On 03/26/2015 01:09 AM, Ian Kelly wrote:
>
>
> 
https://docs.python.org/3/reference/lexical_analysis.html#string-literal-concatenation


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.



That's the way I also read the BNF.  But something I cannot find in that 
chapter of the reference is the definition of STRING+


Naturally searching for 'string' finds way too many spurious refs.



--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list

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

[Ian Kelly]

On Wed, Mar 25, 2015 at 10:35 PM, Thomas 'PointedEars' Lahn
 wrote:
> Chris Angelico wrote:
>
>> On Sun, Mar 22, 2015 at 2:49 PM, 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+. 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

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

[Thomas 'PointedEars' Lahn]

Chris Angelico wrote:

> On Sun, Mar 22, 2015 at 2:49 PM, 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.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Marko Rauhamaa]

Thomas 'PointedEars' Lahn :

> | atom: ('(' [yield_expr|testlist_comp] ')' |
> |'[' [testlist_comp] ']' |
> |'{' [dictorsetmaker] '}' |
> |NAME | NUMBER | STRING+ | '...' | 'None' | 'True' | 'False')
>
> [Chris Angelico wrote:]
>> Implicit concatenation is part of the syntax, not part of the
>> expression evaluator.
>
> Reads like nonsense to me.

The two of you are fighting over nothing. IOW, you aren't in
disagreement.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Sun, Mar 22, 2015 at 2:49 PM, 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? String concatenation by abuttal is as much a
syntactic element as the distinction between regular, raw, and
triple-quoted string literals. By the time you get to AST (never mind
about byte code), that information is gone:

>>> print(ast.dump(ast.parse("""
... x = '''hello'''
... """)))
Module(body=[Assign(targets=[Name(id='x', ctx=Store())], value=Str(s='hello'))])
>>> print(ast.dump(ast.parse("""
... x = r'hello'
... """)))
Module(body=[Assign(targets=[Name(id='x', ctx=Store())], value=Str(s='hello'))])
>>> print(ast.dump(ast.parse("""
... x = "hello"
... """)))
Module(body=[Assign(targets=[Name(id='x', ctx=Store())], value=Str(s='hello'))])
>>> print(ast.dump(ast.parse("""
... x = "he" "ll" "o"
... """)))
Module(body=[Assign(targets=[Name(id='x', ctx=Store())], value=Str(s='hello'))])

Nothing in the expression evaluator knows or cares about what kind of
string literal you used, nor whether you included more than one. It's
all just alternative forms of string literal.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

Chris Angelico wrote:

> On Sun, Mar 22, 2015 at 2:14 PM, Thomas 'PointedEars' Lahn
>  wrote:
>> Denis McMahon wrote:
>>> However, you can't have multiple expressions on a line without some sort
>>> of operand or separator between them.
>> String concatenation is implicit in Python, but only with string
>> *literals*:
> 
> Which aren't expressions.

IBTD:

,-
| 
| […]
| expr: xor_expr ('|' xor_expr)*
| xor_expr: and_expr ('^' and_expr)*
| and_expr: shift_expr ('&' shift_expr)*
| shift_expr: arith_expr (('<<'|'>>') arith_expr)*
| arith_expr: term (('+'|'-') term)*
| term: factor (('*'|'/'|'%'|'//') factor)*
| factor: ('+'|'-'|'~') factor | power
| power: atom trailer* ['**' factor]
| atom: ('(' [yield_expr|testlist_comp] ')' |
|'[' [testlist_comp] ']' |
|'{' [dictorsetmaker] '}' |
|NAME | NUMBER | STRING+ | '...' | 'None' | 'True' | 'False')

> Implicit concatenation is part of the syntax, not part of the expression 
> evaluator.

Reads like nonsense to me.
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Sun, Mar 22, 2015 at 2:14 PM, Thomas 'PointedEars' Lahn
 wrote:
> Denis McMahon wrote:
>
>> However, you can't have multiple expressions on a line without some sort
>> of operand or separator between them.
>
> String concatenation is implicit in Python, but only with string *literals*:

Which aren't expressions. Implicit concatenation is part of the
syntax, not part of the expression evaluator.

https://docs.python.org/2/reference/lexical_analysis.html#string-literal-concatenation
https://docs.python.org/3/reference/lexical_analysis.html#string-literal-concatenation

> (I wished other programming languages had this feature.)

But I absolutely agree. A handful do (Pike, with the same semantics as
Python; REXX, but with the proviso that any amount of whitespace
between the literals becomes a single space in the resulting string),
and it really is a very handy feature.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

Denis McMahon wrote:

> However, you can't have multiple expressions on a line without some sort
> of operand or separator between them.

String concatenation is implicit in Python, but only with string *literals*:

| $ python
| Python 2.7.9 (default, Mar  1 2015, 12:57:24) 
| [GCC 4.9.2] on linux2
| Type "help", "copyright", "credits" or "license" for more information.
| >>> 'foo' 'bar'
| 'foobar'

| $ python3
| Python 3.4.2 (default, Dec 27 2014, 13:16:08) 
| [GCC 4.9.2] on linux
| Type "help", "copyright", "credits" or "license" for more information.
| >>> 'foo' 'bar'
| 'foobar'

They do not even have to be on the same line:

| $ python <<'EOT'
| print("foo"
|   "bar")
| EOT
| foobar

| $ python3 <<'EOT'
| print("foo"
|   "bar")
| EOT
| foobar

(I wished other programming languages had this feature.)

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Denis McMahon]

On Wed, 18 Mar 2015 10:46:20 -0700, Aditya Raj Bhatt wrote:

> I always do single line comments with # but just for the sake of it I
> tried it with ''' ''' and it gives me a syntax error.

> ...

> So can someone tell me why a triple-quoted string gives a syntax error
> if only in one line?

A triple quoted string is a multiline string literal. A string literal 
(of any sort) is a basic python expression.

An expression is often, but by no means exclusively, part of an 
assignment statement. However, an expression may also exist just as a 
simple expression.

There is nothing special about a triple quoted string that makes it a 
comment, other than it is sometimes used as such in it's guise as a basic 
expression.

However, you can't have multiple expressions on a line without some sort 
of operand or separator between them.

a = 5 '''text'''

is just as wrong as:

q = 4,5,6   [3,5,7,9]

or

k = 6-2  {56:91, 'fred': 'peter'}

or even

m = 62.3   56.7   101.2

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Ben Finney]

Aditya Raj Bhatt  writes:

> I always do single line comments with # but just for the sake of it I
> tried it with ''' ''' and it gives me a syntax error.

The only comment syntax in Python code is the line-end ‘# …’ syntax.

> In both the interpreter, and the source code text file, doing -
>
> a = 5 '''a comment'''

There is no comment on that line. You have an assignment statement
immediately followed by a string literal, which is invalid syntax.

> http://stackoverflow.com/questions/397148/why-doesnt-python-have-multiline-comments
> which says that there are no 'true' multiline comments in python and
> that all those 'block' comments are actually triple-quoted strings.

That's correct.

> So can someone tell me why a triple-quoted string gives a syntax error
> if only in one line?

Because the string literal – it doesn't matter how it's quoted – can
only appear where the syntax allows for a string literal. It isn't a
comment, so it can't be freely substituted for a comment.

> Can someone also provide a sort of a 'guide' to triple-quoted comments
> in general?

The guide is simple: There are no triple-quoted comments in Python.

If you triple-quote a string literal, it is still a string literal and
must follow all the syntax rules for string literals.

-- 
 \ “[The RIAA] have the patience to keep stomping. They're playing |
  `\ whack-a-mole with an infinite supply of tokens.” —kennon, |
_o__) http://kuro5hin.org/ |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Thu, Mar 19, 2015 at 9:58 AM, Steven D'Aprano
 wrote:
> But let's also remember that sometimes you cannot be bothered with *best*
> practice, and "good enough for now" practice is fine.
>
> Need to comment out a large block of code in a hurry while using a basic
> editor that doesn't offer a "Comment" and "Uncomment" command? Best
> practice says I should use a better editor, and that's fine, but right this
> instant I'm using the tools I have, not the tools I want, and the easiest
> way to fix this is to surround the block of code with triple-quotes. I can
> always come back and fix it later. Famous last words, I know, but who among
> us can truthfully say they have *never* taken a quick and dirty short-cut
> while programming?

There are three broad types of comments:

1) Single-line or to-end-of-line comments, started with a # or a // or
something. Python supports these, they're easy to work with and
recognize. No problem.
2) Block comments, consisting of a number of entire lines of either
text or commented-out code.
3) Partial-line comments - /* comment */ in C-like languages.

You can abuse triple-quoted strings to do #2, but not #3. For
instance, in C, you can legally do something like this:

if (condition1 /* && condition2 */) do_stuff();

In terms of "quick and dirty short-cuts", that's one that I miss
having a mechanic for in Python. And yes, you can decry it as a bad
practice, but just as with Steven's example, it's always with the plan
to fix it later (usually by making the code more flexible in some
way), and yet does sometimes stay in the code for a rather long time,
for the same reason that several of my Alice posters are currently
lying face down on the Alice Shelf instead of being up on the wall -
there's nothing more permanent than a temporary solution.

(There's also technically a fourth use of slash-star comments -
beginning part way into one line and ending part way into another
line:

code code /* blah blah
blah blah
blah */ more code

But if you do this on a regular basis, I think we are justified in
throwing rotten fruit at you.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Thu, 19 Mar 2015 06:53 am, Thomas 'PointedEars' Lahn wrote:

> I must strongly object and recommend against getting accustomed to the
> suggested use of multi-line string literals.

I agree in general with Thomas' comments about using arbitrary strings as
comments. If you want to write code according to *best practices*, then you
should not use strings as comments.

But let's also remember that sometimes you cannot be bothered with *best*
practice, and "good enough for now" practice is fine.

Need to comment out a large block of code in a hurry while using a basic
editor that doesn't offer a "Comment" and "Uncomment" command? Best
practice says I should use a better editor, and that's fine, but right this
instant I'm using the tools I have, not the tools I want, and the easiest
way to fix this is to surround the block of code with triple-quotes. I can
always come back and fix it later. Famous last words, I know, but who among
us can truthfully say they have *never* taken a quick and dirty short-cut
while programming?

I also find it convenient and unobjectionable to include a bare triple
quoted string at the very end of the file, as a sort of "note pad" area for
me to write notes to myself while the work is in early stages of progress.
I can put in small code snippets, URLs to pages I need to look at, general
comments, etc. without having to care about leading # signs. And because I
don't use strings for comments anywhere else, this note pad area stands out
and reminds me to remove it before releasing the code into production.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Terry Reedy]

On 3/18/2015 3:53 PM, Thomas 'PointedEars' Lahn wrote:


I must strongly object and recommend against getting accustomed to the
suggested use of multi-line string literals.


I agree.


If you want to comment your code, then by all means do so using docstrings
and *real* comments.  IDEs like PyDev support you there.


For instance, with Idle, before (with red comment coloring):

# this is
# a very very very ragged ragged ragged ragged ragged ragged ragged
# multiline comment
# that I will reformat
# with Idle's Format Paragraph (default key binding alt-Q, but this may 
be reset by the user as long as the user is careful to not resuse 
another key.


after alt-q anywhere in the comment block, with default 72 char lines

# this is a very very very ragged ragged ragged ragged ragged ragged
# ragged multiline comment that I will reformat with Idle's Format
# Paragraph (default key binding alt-Q, but this may be reset by the
# user as long as the user is careful to not resuse another key.


That way also the syntax highlighting will be correct.



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

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

[Tim Chase]

On 2015-03-18 10:46, Aditya Raj Bhatt wrote:
> a = 5 '''a comment'''
> 
> results in a syntax error

That's to be expected, and happens with any string, not just
triple-quoted:

  >>> a = 5 "hello"

> there are no 'true' multiline comments in python and that all those
> 'block' comments are actually triple-quoted strings.

Yes, that's an abuse of strings.  It works nicely for doc-strings,
but I avoid it for everything else.

> So can someone tell me why a triple-quoted string gives a syntax
> error if only in one line?

When a string (triple-quoted or otherwise) begins at the beginning of
a line, its return value is ignored at compile-time:

>>> def a():
... print 1
... "test"
... print 2
... 
>>> import dis
>>> dis.dis(a)
  2   0 LOAD_CONST   1 (1)
  3 PRINT_ITEM  
  4 PRINT_NEWLINE   

  4   5 LOAD_CONST   2 (2)
  8 PRINT_ITEM  
  9 PRINT_NEWLINE   
 10 LOAD_CONST   0 (None)
 13 RETURN_VALUE

Note that nothing appears in the byte-code for line #3.  They Python
interpreter/compiler is smart enough to know that the string can be
discarded.

> Actually, there are other confusions I have too, regarding using
> backslashes inside triple-quoted strings to form multi-line
> comments, and a general uncertainty about triple-quoted strings.
>
> Can someone also provide a sort of a 'guide' to triple-quoted
> comments in general?

Triple-quoted strings aren't particularly magical other than that
they allow you to have multi-line strings and it allows you to have
both single and double quotes inside the string with less mess than
if you have them mixed in a regular string (where you'd need to
escape at least one of them).

  s1 = "Single ' and double \" quotes"
  s2 = 'Single \' and double " quotes'
  s3 = """Single ' and double " quotes"""

If you want to avoid some of the backslash issues, you can make it a
raw triple-quoted string:

  s = r"""this is in
  c:\temp\new>
  for you to test
  """

Note the leading "r" before the quotes.  This is what tells Python
not to translate the "\t" and "\n" in the following content.

-tkc


-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

Aditya Raj Bhatt wrote:

> I always do single line comments with # but just for the sake of it I
> tried it with ''' ''' and it gives me a syntax error.
> 
> In both the interpreter, and the source code text file, doing -
> 
> a = 5 '''a comment'''
> 
> results in a syntax error, with the very last quote at the end of the
> line highlighted in red. […]
> 
> So can someone tell me why a triple-quoted string gives a syntax error
> if only in one line?

As with all syntax errors in all programming languages, the code cannot be 
produced by the grammar (here: 
, assuming Python 3.x).

> Actually, there are other confusions I have too,
> regarding using backslashes inside triple-quoted strings to form
> multi-line comments, and a general uncertainty about triple-quoted
> strings.
> 
> Can someone also provide a sort of a 'guide' to triple-quoted comments
> in general?

Do not use them as comments in this way.  See also my other follow-up.

[x] done

> Something like how I can just sum up index slices by saying in [a:b],
> the 'counting' for a always starts with 0, a is included, everything up
> to b but not b is included (assuming this is in fact the correct
> explanation ;-))

It is correct:






-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> […] standalone multi-line string literals in Python code serve a specific
> purpose when at the beginning of a function, method or class clock: they 
   ^ block¹
> constitute *docstrings”, setting

_
¹  Apparently I am doing to much relativity lately ;-)

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas 'PointedEars' Lahn]

Laurent Pointal wrote:

> Laurent Pointal wrote:
>> Take care of indent:
>> 
>> def f(x):
>> a = 5
>> """an correctly indented expression to be
>> inside the function"""
>> return a * x
> 
> Here only the first indent of """ at beginning of the string to be aligned
> to function bloc is important, remaining content of the string can be
> indented or not.

I must strongly object and recommend against getting accustomed to the 
suggested use of multi-line string literals.  First of all, it is too easy 
to produce invalid code this way.  Also, standalone multi-line string 
literals in Python code serve a specific purpose when at the beginning of a 
function, method or class clock: they constitute *docstrings”, setting the 
respective object’s “__doc__” attribute:

>>> def f(x):
..."""Returns a multiple of 5"""
...a = 5
...return a * x
... 
>>> print(f.__doc__)
Returns a multiple of 5

This means that different to real comments, the content of string literals 
is *parsed*.  You do not want to waste the time of the compiler compiling 
code that serves no purpose; particularly not in a language like Python 
where code is JIT-compiled by default.

Not any less important: Using standalone multi-line string literals in any 
other way is syntactically correct indeed, but makes the code harder to 
read.  Keep in mind that code may be written only once, but read many times 
by other people during its lifetime.  It is important to write code so that 
it is easy to read, so that it can be easily reused and adapted by oneself 
and others (a month, a year later).

If you want to comment your code, then by all means do so using docstrings 
and *real* comments.  IDEs like PyDev support you there.  That way also the 
syntax highlighting will be correct.  And with real comments, the Python 
compiler does not care about the indentation.  As to where you should put 
comments, I recommend in general, in all programming languages, if possible 
to put the comments on their own line, *before* the statement that they are 
describing, and using the same indentation, preferably preceded by an empty 
line (so that the comment and the code it documents stand out).




-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Laurent Pointal]

Aditya Raj Bhatt wrote:

> On Wednesday, March 18, 2015 at 1:04:39 PM UTC-5, Laurent Pointal wrote:
>> > Can someone also provide a sort of a 'guide' to triple-quoted
> comments
>> > in general?
>> 
>> A triple ' or " string is a Python string, allowing line-return in
> string.
> 
> What do you mean by line-return in string? Is it newline? Does it mean I
> can write -
> 
> '''first part
> second part'''
> 
> ?

Yes.

>> If it is in an expression (like a = 5 '''a comment'''), then it must
> be a
>> valid expression (and here it is not).
> 
> What is not a valid expression here?

What do you expect as result of this combination of an integer with a 
string?

>>> a = 5 '''a comment'''
  File "", line 1
a = 5 '''a comment'''
^
SyntaxError: invalid syntax

You may use an *, and you buid a valid expression with a result

>>> a = 5 * '''a comment'''

But… this may not be the value you wanted for a variable.

>>> a
'a commenta commenta commenta commenta comment'

So, a string is really not a comment, even if triple quote strings can be 
used alone to store multi-line "comments".

A+
Laurent.

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Igor Korot]

 Hi,

On Wed, Mar 18, 2015 at 2:23 PM, Aditya Raj Bhatt
 wrote:
> On Wednesday, March 18, 2015 at 1:04:39 PM UTC-5, Laurent Pointal wrote:
>> > Can someone also provide a sort of a 'guide' to triple-quoted
> comments
>> > in general?
>>
>> A triple ' or " string is a Python string, allowing line-return in
> string.
>
> What do you mean by line-return in string? Is it newline? Does it mean I
> can write -
>
> '''first part
> second part'''
>
> ?
>
>> If it is in an expression (like a = 5 '''a comment'''), then it must
> be a
>> valid expression (and here it is not).
>
> What is not a valid expression here?

a = 5 #Valid expression
b = c + d # Valid expression
a = 5 b = c + d # Invalid expression

a = 5 # Valid expression
''' testing comment ''' # Valid expression
a = 5 ''' testing comment ''' #Invalid expression

Thank you.
>
>>
>> A+
>> Laurent.
>
> Thank you for the fast and detailed response,
> Aditya
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Aditya Raj Bhatt]

On Wednesday, March 18, 2015 at 1:04:39 PM UTC-5, Laurent Pointal wrote:
> > Can someone also provide a sort of a 'guide' to triple-quoted
comments
> > in general?
> 
> A triple ' or " string is a Python string, allowing line-return in
string.

What do you mean by line-return in string? Is it newline? Does it mean I
can write -

'''first part
second part'''

?
 
> If it is in an expression (like a = 5 '''a comment'''), then it must
be a 
> valid expression (and here it is not).

What is not a valid expression here?
 
> 
> A+
> Laurent.

Thank you for the fast and detailed response,
Aditya
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Laurent Pointal]

Laurent Pointal wrote:

(oups)
> Take care of indent:
> 
> def f(x):
> a = 5
> """an correctly indented expression to be
> inside the function"""
> return a * x

Here only the first indent of """ at beginning of the string to be aligned 
to function bloc is important, remaining content of the string can be 
indented or not.



-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Laurent Pointal]

Aditya Raj Bhatt wrote:

> I always do single line comments with # but just for the sake of it I
> tried it with ''' ''' and it gives me a syntax error.
> 
> In both the interpreter, and the source code text file, doing -
> 
> a = 5 '''a comment'''
> 
> results in a syntax error, with the very last quote at the end of the
> line highlighted in red. Of course, if I do -
> 
> a = 5 #'''a comment'''

> Can someone also provide a sort of a 'guide' to triple-quoted comments
> in general?

A triple ' or " string is a Python string, allowing line-return in string.

If it is in an expression (like a = 5 '''a comment'''), then it must be a 
valid expression (and here it is not).

You can have an expression alone, with no stored result (ie. no assignment 
to a name), and this is how are used triple quoted strings as comments.

a = 5
"""a comment"""

Take care of indent:

def f(x):
a = 5
"""an correctly indented expression to be
inside the function"""
return a * x

A+
Laurent.

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Aditya Raj Bhatt]

I always do single line comments with # but just for the sake of it I
tried it with ''' ''' and it gives me a syntax error.

In both the interpreter, and the source code text file, doing -

a = 5 '''a comment'''

results in a syntax error, with the very last quote at the end of the
line highlighted in red. Of course, if I do -

a = 5 #'''a comment'''

it works. I searched for the problem, and arrived at
http://stackoverflow.com/questions/397148/why-doesnt-python-have-multiline-comments
which says that there are no 'true' multiline comments in python and
that all those 'block' comments are actually triple-quoted strings. Then
I looked in the documentation and found
https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals
but it is a little bit too complex for my understanding (I'm just
starting python). 

So can someone tell me why a triple-quoted string gives a syntax error
if only in one line? Actually, there are other confusions I have too,
regarding using backslashes inside triple-quoted strings to form
multi-line comments, and a general uncertainty about triple-quoted
strings.

Can someone also provide a sort of a 'guide' to triple-quoted comments
in general?
Something like how I can just sum up index slices by saying in [a:b],
the 'counting' for a always starts with 0, a is included, everything up
to b but not b is included (assuming this is in fact the correct
explanation ;-))

-- 
https://mail.python.org/mailman/listinfo/python-list