Mailman 3 Re: [Python-ideas] allow line break at operators - Python-ideas

newer
truncate sequences in pretty-print...

Re: [Python-ideas] allow line break at operators

older
Re: [Python-ideas] [Python-Dev]...

MRAB

4 Sep 2011 4 Sep '11

7:59 p.m.

On 04/09/2011 00:22, Yingjie Lan wrote:

...

On 04/09/2011 03:04, MRAB wrote:

...
I think that the rules would be:

If a line ends with a colon and the next line is indented, then it's the start of a block, and the following lines which belong to that block have the same indent.

If a line doesn't end with a colon but the next line is indented, then it's the start of a continuation, and the following lines which belong to that continuation have the same indent.

In both cases there could be blocks nested in blocks and possibly continuations nested in continuations, as well as blocks nested in continuations and continuations nested in blocks.

I'm not sure what the effect would be if you had mis-indented lines. For example, if a line was accidentally indented after a comment, then it would be treated as part of the comment. It's in cases like those that syntax colouring would be helpful. It would be a good idea to use an editor which could indicate in some way when a line is a continuation.

Thanks, I think that's the rule described in its full glory. Currently I am not quite sure of the use case for continuation nested in continuation -- it seems to be still a single continuation, but it allows for some additional freedom in formatting the continued line. Do you have other use cases for that?

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

...

For the case of mis-indentation, as demonstrated in your scenario, I think it is better that the rule is not applied to a comment continued onto the next line. The effect of a '#' only carries to the end of a line, if one would like the next line to be a comment, just use another '#'. It remains to consider a mis-indentation that only involves code lines. However, that is not a new problem, so we should not worry (it is like a sunken cost).

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.

Show replies by date

Ben Finney

5 Sep 5 Sep

12:26 a.m.

New subject: allow line break at operators

MRAB writes:

...

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

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

12:39 a.m.

New subject: allow line break at operators

Ben Finney writes:

...

MRAB writes:

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

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

Arnaud Delobelle

17 Sep 17 Sep

11:18 p.m.

New subject: allow line break at operators

On 4 September 2011 23:39, Ben Finney wrote:

...

Ben Finney writes:

...
MRAB writes:

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

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

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:

...

...
...
dis.dis(bar) 1 0 LOAD_CONST 3 ('ab') 3 RETURN_VALUE

-- Arnaud

Steven D'Aprano

18 Sep 18 Sep

4:18 a.m.

New subject: allow line break at operators

Arnaud Delobelle wrote:

...

On 4 September 2011 23:39, Ben Finney wrote:

...
Ben Finney writes:

...
MRAB writes:

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

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.

...

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:

...
...
...
dis.dis(bar) 1 0 LOAD_CONST 3 ('ab') 3 RETURN_VALUE

I'm not entirely sure I understand your point there. That's the keyhole optimizer at work. It does the same thing here:

...

...
...
dis.dis(compile("1+1", "", "single")) 1 0 LOAD_CONST 2 (2) 3 PRINT_EXPR 4 LOAD_CONST 1 (None) 7 RETURN_VALUE

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

Arnaud Delobelle

8:26 a.m.

New subject: allow line break at operators

On 18 September 2011 03:18, Steven D'Aprano wrote:

...

Arnaud Delobelle wrote:

...
On 4 September 2011 23:39, Ben Finney wrote:

...
Ben Finney writes:

...
MRAB writes:

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

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

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.

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

...
...
...
dis.dis(bar)

1 0 LOAD_CONST 3 ('ab') 3 RETURN_VALUE

I'm not entirely sure I understand your point there.

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

Ben Finney

12:22 p.m.

New subject: allow line break at operators

Arnaud Delobelle writes:

...

On 4 September 2011 23:39, Ben Finney wrote:

...
Ben Finney writes:

...
How many string literals do you count in the following statement? I count one:

raise HoustonWeHaveAProblemError( "Lorem ipsum dolor sit amet," " consectetur adipiscing elit.")

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.

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

Georg Brandl

12:46 p.m.

New subject: allow line break at operators

Am 18.09.2011 12:22, schrieb Ben Finney:

...

Arnaud Delobelle writes:

...
On 4 September 2011 23:39, Ben Finney wrote:

...
Ben Finney writes:

...
How many string literals do you count in the following statement? I count one:

raise HoustonWeHaveAProblemError( "Lorem ipsum dolor sit amet," " consectetur adipiscing elit.")

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.

Hmm. So how should I be looking to answer the question? My AST-fu is weak.

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

Ben Finney

1:38 p.m.

New subject: allow line break at operators

Georg Brandl writes:

...

Am 18.09.2011 12:22, schrieb Ben Finney:

...
Arnaud Delobelle writes:

...
On 4 September 2011 23:39, Ben Finney wrote:

...
Ben Finney writes:

...
How many string literals do you count in the following statement? I count one:

raise HoustonWeHaveAProblemError( "Lorem ipsum dolor sit amet," " consectetur adipiscing elit.")

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.

Hmm. So how should I be looking to answer the question? My AST-fu is weak.

It is sufficient to look into Grammar/Grammar:

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

Nick Coghlan

1:56 p.m.

New subject: allow line break at operators

On Sun, Sep 18, 2011 at 9:38 PM, Ben Finney wrote:

...

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?

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

...

...
...
ast.dump(compile("'Hello ' 'World!'", "<ast>", "eval", flags=ast.PyCF_ONLY_AST)) "Expression(body=Str(s='Hello World!'))" ast.dump(compile("'Hello ' + 'World!'", "<ast>", "eval", flags=ast.PyCF_ONLY_AST)) "Expression(body=BinOp(left=Str(s='Hello '), op=Add(), right=Str(s='World!')))"

Not that even the AST is post the implicit string concatenation step, though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Nick Coghlan

1:57 p.m.

New subject: allow line break at operators

On Sun, Sep 18, 2011 at 9:56 PM, Nick Coghlan 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

Guido van Rossum

4:54 p.m.

New subject: allow line break at operators

On Sun, Sep 18, 2011 at 4:38 AM, Ben Finney wrote:

...

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?

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

5 Sep 5 Sep

1:01 a.m.

New subject: allow line break at operators

On 04/09/2011 23:26, Ben Finney wrote:

...

MRAB writes:

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

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

It depends on how you count them. :-) What I mean is that I'd still forbid a newline between the quotes. Is this acceptable? "Lorem ipsum dolor sit amet, consectetur adipiscing elit." I'd say not.

Ben Finney

1:21 a.m.

New subject: allow line break at operators

MRAB writes:

...

What I mean is that I'd still forbid a newline between the quotes. Is this acceptable?

"Lorem ipsum dolor sit amet, consectetur adipiscing elit."

I'd say not.

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

4602

Age (days ago)

4616

Last active (days ago)

List overview

Download

13 comments

7 participants

participants (7)

Arnaud Delobelle
Ben Finney
Georg Brandl
Guido van Rossum
MRAB
Nick Coghlan
Steven D'Aprano

Re: [Python-ideas] allow line break at operators

tags

participants (7)