My inclination would be to cede code formatting to a tool like Black and focus on function: https://black.readthedocs.io/en/stable/ On Fri, 2021-03-12 at 15:32 +0000, Matt Williams wrote:

Hi,

It's becoming more popular in Python to have interfaces which are built around method chaining as a way of applying operations to data. For example in pandas is moving more towards a default model where methods do not change the object in-place but instead return an altered version (or at least an altered view) of it.

The major downside to method chaining is that it ends up creating long lines of code which can become hard to read. The two main solutions to this are 1) break down the chain and give the steps their own variable names and 2) split it over multiple lines using `\` as a line continuation.

e.g.:

  y = x.rstrip("\n").split(":")[0].lower()

would become

  y = x.rstrip("\n") \        .split(":")[0] \        .lower()

I find the continuation character visually distracting, easy to forget and does not allow for line-by-line commenting (causing `SyntaxError: unexpected character after line continuation character`):

  y = x.rstrip("\n") \        .split(":")[0] \  # grab the key name        .lower()

My idea is to alter the syntax of Python to allow doing:

  y = x.rstrip("\n")        .split(":")[0]        .lower()

i.e., not requiring an explicit line continuation character in the case where the next line starts with a period.

I've had a search through the archives and I couldn't see this discussion before. Feel free to point me to it if I've missed anything.

Cheers, Matt _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LWB3U5... Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, Mar 12, 2021 at 10:41 AM Matt Williams wrote:

Hi,

It's becoming more popular in Python to have interfaces which are built around method chaining as a way of applying operations to data. For example in pandas is moving more towards a default model where methods do not change the object in-place but instead return an altered version (or at least an altered view) of it.

The major downside to method chaining is that it ends up creating long lines of code which can become hard to read. The two main solutions to this are 1) break down the chain and give the steps their own variable names and 2) split it over multiple lines using `\` as a line continuation.

e.g.:

y = x.rstrip("\n").split(":")[0].lower()

would become

y = x.rstrip("\n") \ .split(":")[0] \ .lower()

I find the continuation character visually distracting, easy to forget and does not allow for line-by-line commenting (causing `SyntaxError: unexpected character after line continuation character`):

y = x.rstrip("\n") \ .split(":")[0] \ # grab the key name .lower()

My idea is to alter the syntax of Python to allow doing:

y = x.rstrip("\n") .split(":")[0] .lower()

i.e., not requiring an explicit line continuation character in the case where the next line starts with a period.

I've had a search through the archives and I couldn't see this discussion before. Feel free to point me to it if I've missed anything.

Why isn't the implicit line continuation inside parentheses sufficient? From my 3.9 REPL:

...

...

x 'TEST:TESTING:TEST3\n' y = x.rstrip("\n").split(":")[0].lower() y 'test' z = (x.rstrip("\n") ... .split(":")[0] ... .lower() ... ) z 'test'

This already works today, and every style guide with an opinion that I'm aware of prefers this implicit line continuation over the explicit backslash you demonstrate anyway.

To my mind there are too many differences between running code as a script and running it in the REPL.  This would, presumably, add another one: the initial line would be executed without waiting to see if there is a dot continuation line.  And it just feels wrong to have a complete syntactically valid line of code ... not be a complete line of code.  You can always add outer brackets, as in other situations where lines of code become over-long: y = (x.rstrip("\n") .split(":")[0] .lower()) -1 Rob Cliffe On 12/03/2021 15:32, Matt Williams wrote:

Hi,

It's becoming more popular in Python to have interfaces which are built around method chaining as a way of applying operations to data. For example in pandas is moving more towards a default model where methods do not change the object in-place but instead return an altered version (or at least an altered view) of it.

The major downside to method chaining is that it ends up creating long lines of code which can become hard to read. The two main solutions to this are 1) break down the chain and give the steps their own variable names and 2) split it over multiple lines using `\` as a line continuation.

e.g.:

y = x.rstrip("\n").split(":")[0].lower()

would become

y = x.rstrip("\n") \ .split(":")[0] \ .lower()

I find the continuation character visually distracting, easy to forget and does not allow for line-by-line commenting (causing `SyntaxError: unexpected character after line continuation character`):

y = x.rstrip("\n") \ .split(":")[0] \ # grab the key name .lower()

My idea is to alter the syntax of Python to allow doing:

y = x.rstrip("\n") .split(":")[0] .lower()

i.e., not requiring an explicit line continuation character in the case where the next line starts with a period.

I've had a search through the archives and I couldn't see this discussion before. Feel free to point me to it if I've missed anything.

Cheers, Matt _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LWB3U5... Code of Conduct: http://python.org/psf/codeofconduct/

I have written tens of thousands of lines of Pandas code, and I've taught thousands of people to use Pandas. I've worked with the core developers of Pandas as well. This is the first time I've ever seen `\` line continuation used for fluent programming style rather than just using parentheses as a way of expressing a logical line. On Fri, Mar 12, 2021, 10:41 AM Matt Williams wrote:

Hi,

It's becoming more popular in Python to have interfaces which are built around method chaining as a way of applying operations to data. For example in pandas is moving more towards a default model where methods do not change the object in-place but instead return an altered version (or at least an altered view) of it.

The major downside to method chaining is that it ends up creating long lines of code which can become hard to read. The two main solutions to this are 1) break down the chain and give the steps their own variable names and 2) split it over multiple lines using `\` as a line continuation.

e.g.:

y = x.rstrip("\n").split(":")[0].lower()

would become

y = x.rstrip("\n") \ .split(":")[0] \ .lower()

I find the continuation character visually distracting, easy to forget and does not allow for line-by-line commenting (causing `SyntaxError: unexpected character after line continuation character`):

y = x.rstrip("\n") \ .split(":")[0] \ # grab the key name .lower()

My idea is to alter the syntax of Python to allow doing:

y = x.rstrip("\n") .split(":")[0] .lower()

i.e., not requiring an explicit line continuation character in the case where the next line starts with a period.

I've had a search through the archives and I couldn't see this discussion before. Feel free to point me to it if I've missed anything.

Cheers, Matt _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LWB3U5... Code of Conduct: http://python.org/psf/codeofconduct/

Guido van Rossum wrote:

Can we skip ahead to considering how to implement this? I can think of two approaches: either hack the lexer to special-case a newline followed by a period (which currently can never start a line), or redesign the syntax to allow NEWLINE INDENT ‘.’ ......... NEWLINE ‘.’ ............ DEDENT at the end of an expression. Both have pros and cons. Discuss how this allows for certain typos to pass as valid syntax.

IIRC, BCPL's compiler would continue and expression on the next line if a line ended with an operator. E.g.: x = a + b would parse like x = (a + b); (I think this was a bit more general - if a line didn't end with ";", the parser would try adding a ";" and if that failed to parse, it would continue to the next line.) This leads result in a different style for method-chaining: y = x.rstrip("\n"). split(":")[0]. lower() ... and if you don't like ending lines with a ".", you could always add a parenthesis: y = (x.rstrip("\n") .split(":")[0] .lower()) [I wonder why C didn't adopt BCPL's convention for eliding semi-colons? ...]

On Fri, 12 Mar 2021 at 18:27, Guido van Rossum wrote:

On Fri, Mar 12, 2021 at 6:23 PM Peter Ludemann wrote:

...

[I wonder why C didn't adopt BCPL's convention for eliding semi-colons? ...]

[Presumably because it caused too many surprising behaviors...]

My guess is that it would have been more work in the parser, and therefore didn't fit with Unix "minimalism". ;) It's not clear to me what surprising behaviors there would be. Javascript seems to do OK with optional semicolons - presumably its algorithm is similar to what BCPL used. (Or perhaps the surprising behaviors are trivial compared to the other surprises that Javascript springs on people.)

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...

Chris Angelico wrote:

On Sat, Mar 13, 2021 at 1:46 PM Peter Ludemann peter.ludemann@gmail.com wrote:

...

It's not clear to me what surprising behaviors there would be. Javascript seems to do OK with optional semicolons - presumably its algorithm is similar to what BCPL used. (Or perhaps the surprising behaviors are trivial compared to the other surprises that Javascript springs on people.) Yes, right up until you try to do something like: function foo() { return thing.goes.here() } which becomes extremely common with frameworks like React.js. There's an implicit semicolon and a big block of dead code. ChrisA

def foo(): return thing.goes.here() is illegal Python; and wouldn't result in a line-join by my proposal. However: def foo(): return "A long piece of text (Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.)" + thing.goes.here() would work by my proposal and avoid the extra parentheses that are currently needed.