Re: [Python-ideas] allow line break at operators
On 04/09/2011 00:22, Yingjie Lan wrote:
I don't have a use-case, I was just wondering whether in this: first second third fourth "third" is a continuation, giving this: first second third fourth which has 2 continuations, leading to this: first second third fourth
As well as still limiting a comment to a line, I'd also still limit a string literal (except a triple-quoted string literal) to a line.
MRAB <python@mrabarnett.plus.com> writes:
I do this routinely in my code, using bracketing syntax. It's useful for visually showing the structure of moderately complex generator expressions or function calls, for instance.
As well as still limiting a comment to a line, I'd also still limit a string literal (except a triple-quoted string literal) to a line.
How many string literals do you count in the following statement? I count one: raise HoustonWeHaveAProblemError( "Lorem ipsum dolor sit amet," " consectetur adipiscing elit.") -- \ “Creativity can be a social contribution, but only in so far as | `\ society is free to use the results.” —Richard M. Stallman | _o__) | Ben Finney
Ben Finney <ben+python@benfinney.id.au> writes:
The Python compiler agrees with me: >>> import dis >>> def foo(): ... raise ValueError( ... "Lorem ipsum dolor sit amet," ... " consectetur adipiscing elit.") ... >>> dis.dis(foo) 2 0 LOAD_GLOBAL 0 (ValueError) 3 3 LOAD_CONST 1 ('Lorem ipsum dolor sit amet, consectetur adipiscing elit.') 6 CALL_FUNCTION 1 9 RAISE_VARARGS 1 12 LOAD_CONST 0 (None) 15 RETURN_VALUE So if you do mean “limit a string literal to a line” to cover the above case, I disagree. I frequently use the fact that a single-quoted string literal can be broken over multiple lines like the above, to make code more readable. -- \ “The Vatican is not a state.… a state must have territory. This | `\ is a palace with gardens, about as big as an average golf | _o__) course.” —Geoffrey Robertson, 2010-09-18 | Ben Finney
On 4 September 2011 23:39, Ben Finney <ben+python@benfinney.id.au> wrote:
The code object says that there's one string constant in the compiled function. It says nothing (and knows nothing) about the number of string literals that made up this string. In the following, how many string literals can you see?
def bar(): return "a" + "b" ...
Now let's look at the code object:
-- Arnaud
Arnaud Delobelle wrote:
Compile-time implicit concatenation of string literals is a guarantee of the language. Any Python implementation must do that, going back to at least CPython 1.5 and possibly older.
I'm not entirely sure I understand your point there. That's the keyhole optimizer at work. It does the same thing here:
and it is an implementation feature, not a language feature. The oldest version I can find that does this is CPython 2.5, and there's no guarantee that either other implementations or future versions will do the same thing. -- Steven
On 18 September 2011 03:18, Steven D'Aprano <steve@pearwood.info> wrote:
My point is that looking at the number of string constants in compiled code does not tell you the number of string literals in the source code. I thought this was clear from the context of my reply to Ben (see quoted messages above). -- Arnaud
Arnaud Delobelle <arnodel@gmail.com> writes:
Hmm. So how should I be looking to answer the question? My AST-fu is weak. -- \ “Science doesn't work by vote and it doesn't work by | `\ authority.” —Richard Dawkins, _Big Mistake_ (The Guardian, | _o__) 2006-12-27) | Ben Finney
Am 18.09.2011 12:22, schrieb Ben Finney:
It is sufficient to look into Grammar/Grammar: atom: ('(' [yield_expr|testlist_comp] ')' | '[' [listmaker] ']' | '{' [dictorsetmaker] '}' | '`' testlist1 '`' | NAME | NUMBER | STRING+) The little "+" after STRING tells you taht the multiple string literals survive the tokenizer and are concatenated during AST creation (look for parsestrplus() in Python/ast.c). Georg
Georg Brandl <g.brandl@gmx.net> writes:
No, my question is how can I introspect the Python runtime state to compare two statements: foo = "spam" "eggs" bar = "spam" + "eggs" and show that the *result as produced by the parser* is that the first statement has a single string literal on the right hand side, while the second statement has a concatenation expression between two string literals. In other words: once I've come to a hypothesis from my reading of the grammar, how can I *verify* that against the actual running Python language parser? -- \ “Broken promises don't upset me. I just think, why did they | `\ believe me?” —Jack Handey | _o__) | Ben Finney
On Sun, Sep 18, 2011 at 9:38 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
To an arbitrary level, you can't. The ast module gets you pretty close, though, since optimisations aren't applied when you request the AST as the output of compilation: # 3.2
Not that even the AST is post the implicit string concatenation step, though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Sep 18, 2011 at 9:56 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Not that even the AST is post the implicit string concatenation step, though.
s/Not that/Note that/ Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Sep 18, 2011 at 4:38 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
I'm confused why anybody would care about the answer. Is this just to settle an argument where someone claimed that "foo" "bar" was two strings whereas someone else claimed that it was one? You can't answer that by looking at the AST -- you have to think about what the proper definition of string should be. Personally I think of it as two string literals. Maybe that will stop this thread? -- --Guido van Rossum (python.org/~guido)
MRAB <python@mrabarnett.plus.com> writes:
I agree with you on that. But I don't know how to terminologically distinguish that from my example; they're both one string literal. Perhaps we who hold this position should say that “bracketing syntax”, for the purpose of statement continuation, should not include string quotes ‘'’ or ‘"’; we already have triple-quoted strings for that purpose. -- \ “It is wrong to think that the task of physics is to find out | `\ how nature *is*. Physics concerns what we can *say* about | _o__) nature…” —Niels Bohr | Ben Finney
MRAB <python@mrabarnett.plus.com> writes:
I do this routinely in my code, using bracketing syntax. It's useful for visually showing the structure of moderately complex generator expressions or function calls, for instance.
As well as still limiting a comment to a line, I'd also still limit a string literal (except a triple-quoted string literal) to a line.
How many string literals do you count in the following statement? I count one: raise HoustonWeHaveAProblemError( "Lorem ipsum dolor sit amet," " consectetur adipiscing elit.") -- \ “Creativity can be a social contribution, but only in so far as | `\ society is free to use the results.” —Richard M. Stallman | _o__) | Ben Finney
Ben Finney <ben+python@benfinney.id.au> writes:
The Python compiler agrees with me: >>> import dis >>> def foo(): ... raise ValueError( ... "Lorem ipsum dolor sit amet," ... " consectetur adipiscing elit.") ... >>> dis.dis(foo) 2 0 LOAD_GLOBAL 0 (ValueError) 3 3 LOAD_CONST 1 ('Lorem ipsum dolor sit amet, consectetur adipiscing elit.') 6 CALL_FUNCTION 1 9 RAISE_VARARGS 1 12 LOAD_CONST 0 (None) 15 RETURN_VALUE So if you do mean “limit a string literal to a line” to cover the above case, I disagree. I frequently use the fact that a single-quoted string literal can be broken over multiple lines like the above, to make code more readable. -- \ “The Vatican is not a state.… a state must have territory. This | `\ is a palace with gardens, about as big as an average golf | _o__) course.” —Geoffrey Robertson, 2010-09-18 | Ben Finney
On 4 September 2011 23:39, Ben Finney <ben+python@benfinney.id.au> wrote:
The code object says that there's one string constant in the compiled function. It says nothing (and knows nothing) about the number of string literals that made up this string. In the following, how many string literals can you see?
def bar(): return "a" + "b" ...
Now let's look at the code object:
-- Arnaud
Arnaud Delobelle wrote:
Compile-time implicit concatenation of string literals is a guarantee of the language. Any Python implementation must do that, going back to at least CPython 1.5 and possibly older.
I'm not entirely sure I understand your point there. That's the keyhole optimizer at work. It does the same thing here:
and it is an implementation feature, not a language feature. The oldest version I can find that does this is CPython 2.5, and there's no guarantee that either other implementations or future versions will do the same thing. -- Steven
On 18 September 2011 03:18, Steven D'Aprano <steve@pearwood.info> wrote:
My point is that looking at the number of string constants in compiled code does not tell you the number of string literals in the source code. I thought this was clear from the context of my reply to Ben (see quoted messages above). -- Arnaud
Arnaud Delobelle <arnodel@gmail.com> writes:
Hmm. So how should I be looking to answer the question? My AST-fu is weak. -- \ “Science doesn't work by vote and it doesn't work by | `\ authority.” —Richard Dawkins, _Big Mistake_ (The Guardian, | _o__) 2006-12-27) | Ben Finney
Am 18.09.2011 12:22, schrieb Ben Finney:
It is sufficient to look into Grammar/Grammar: atom: ('(' [yield_expr|testlist_comp] ')' | '[' [listmaker] ']' | '{' [dictorsetmaker] '}' | '`' testlist1 '`' | NAME | NUMBER | STRING+) The little "+" after STRING tells you taht the multiple string literals survive the tokenizer and are concatenated during AST creation (look for parsestrplus() in Python/ast.c). Georg
Georg Brandl <g.brandl@gmx.net> writes:
No, my question is how can I introspect the Python runtime state to compare two statements: foo = "spam" "eggs" bar = "spam" + "eggs" and show that the *result as produced by the parser* is that the first statement has a single string literal on the right hand side, while the second statement has a concatenation expression between two string literals. In other words: once I've come to a hypothesis from my reading of the grammar, how can I *verify* that against the actual running Python language parser? -- \ “Broken promises don't upset me. I just think, why did they | `\ believe me?” —Jack Handey | _o__) | Ben Finney
On Sun, Sep 18, 2011 at 9:38 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
To an arbitrary level, you can't. The ast module gets you pretty close, though, since optimisations aren't applied when you request the AST as the output of compilation: # 3.2
Not that even the AST is post the implicit string concatenation step, though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Sep 18, 2011 at 9:56 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Not that even the AST is post the implicit string concatenation step, though.
s/Not that/Note that/ Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Sep 18, 2011 at 4:38 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
I'm confused why anybody would care about the answer. Is this just to settle an argument where someone claimed that "foo" "bar" was two strings whereas someone else claimed that it was one? You can't answer that by looking at the AST -- you have to think about what the proper definition of string should be. Personally I think of it as two string literals. Maybe that will stop this thread? -- --Guido van Rossum (python.org/~guido)
MRAB <python@mrabarnett.plus.com> writes:
I agree with you on that. But I don't know how to terminologically distinguish that from my example; they're both one string literal. Perhaps we who hold this position should say that “bracketing syntax”, for the purpose of statement continuation, should not include string quotes ‘'’ or ‘"’; we already have triple-quoted strings for that purpose. -- \ “It is wrong to think that the task of physics is to find out | `\ how nature *is*. Physics concerns what we can *say* about | _o__) nature…” —Niels Bohr | Ben Finney
participants (7)
-
Arnaud Delobelle -
Ben Finney -
Georg Brandl -
Guido van Rossum -
MRAB -
Nick Coghlan -
Steven D'Aprano