if a == b and c == 1 and d >= 2.7 \ # Here I couldn't use quotations!
I think this might annoy a few people.
1 Like
For sure, it would. We have two simple syntactic features at stake here, namely that of a line continuation and that of a comment. This proposal would make them both more complex.
“SImple is better than complex”
- Say that looking at a barroque styled cathedral
Simple in the case means “less featured”, but ok the negative people are always majority. The idea was thrown.
Well, I positively liked your idea of pushing for a future without backslash-continuations! Of course, it’s really unlikely. In my own code, I never use them.
And if you stop using them, you won’t have to worry about placing comments after them.
1 Like
For what it’s worth, I’ve always thought it was a misfeature to have any kind of line-continuation marking at the end of a line, where it’s harder to notice. I would much rather have a syntax where line continuations are marked at the beginning of the continuation.
3 Likes
The trailing comma would be lonely 
I don’t consider trailing commas to mark a line continuation. The multi-line syntax is already established by bracketing - and I also indent the middle lines in these cases, so the indentation is a beginning-of-line marker in my code.
1 Like
I would write this so:
msg = (
"hello " # comment
"world"
)
and the same with logic:
if (
a == b # comment
or c == d and e == f # comment
):
I just had a squiz at my personal code and all the current line
continuations are things I would do with brackets these days. (And I’ll
be changing them if I ever have cause to modify those bits of code.)
I’m basicly saying that the gains you seem to want from comments after
the continuation marker are all avail using brackets without changing
any syntax at all.
Backslash is not a ‘continuation line bar’. In Python and many other languages, it means ‘give the next char an alternate meaning’. In Python code, the sequence (backslash, line-end) generally means ‘ignore the line-end’. Any other char after backslash is either illegal or means something else. This proposal, based on a misunderstanding of backslash, is a fundamental, breaking change in the meaning of backslash. It is not new and has, I believe, been explicitly rejected previously.
Guido and other core developers are not fans of using backslash to negate line-ends. Not only do fence pairs (parentheses, brackets, and braces) negate all contained line-ends, but the use of grouping parentheses has been expanded to eliminate most/all needs for line-end backslashes. For instance, 3.10 added the use of grouping parentheses to write with statements over multiple lines without using backslash. AFAIK, this was the last required use of backslash, line-end in normal code.
7 Likes
Adding a link for reference: Explicit line joining
1 Like
Although not required, I believe the use of a backslash should continue to be encouraged when embedding a multi-line text that doesn’t start with a blank line:
code = '''\
for i in range(10):
print(i)
'''
versus:
code = '''for i in range(10):
print(i)
'''
unless perhaps Python introduces a shell/perl-like <<END_MARKER syntax:
code = <<EOC
for i in range(10):
print(i)
EOC
which I would be slightly in favor of because it would allow me to embed both ''' and """ in the same literal.
This makes sense as one way to look at it; but the general idea of such an escape sequence is particular to string literals. The backslash-line-end sequence is unique in that it can also appear outside a string literal.
1 Like
Nonetheless, it’s still escaping the newline, whether it’s inside or outside a string literal. It’s just that, outside of a string literal, there aren’t as many things that are worth escaping. (I suppose you could conceivably have Unicode escapes in variable names or something, but why would you?)
In my searches, that does seem to be the most common current use case by a long shot. Probably the last remaining vestige of utility for this syntax.
Personally, I’ll go out of my way to dedent such strings so that I can
eg write:
code = dedent('''
for i in range(10):
print(i)
''')
or something like that.
To me this is better than the top incantation above, which gets
progressively uglier as the opening lis more indented.
And I don’t do this in isolated cases. All my docstrings in personal
code tend to be (a) markdown and (b) shaped like this:
def needdir(dirpath, mode=0o777, *, use_makedirs=False, log=None):
''' Create the directory `dirpath` if missing.
Parameters:
* `dirpath`: the required directory path
* `mode`: the permissions mode, default `0o777`
* `log`: log `makedirs` or `mkdir` call
* `use_makedirs`: optional creation mode, default `False`;
if true, use `os.makedirs`, otherwise `os.mkdir`
'''
I construct simple docs from this stuff, and use a flavour of dedent
which strips the first line and dedents the rest.
2 Likes
The point of a backslash is to avoid the first newline character. dedent doesn’t help with that purpose.
dedent can be combined with a backslash to get the best of both worlds though, as pointed out in my StackOverflow answer:
String literals exist in multiple languages. The idea is also used in regexes, in multiple languages. To me, this is rather general.
Many people were strongly annoyed when Microsoft decided about 40 years ago to use backslash as a separator rather than escape char in file paths. People suffer every day from that choice.
Right, the remaining usage I could not remember ;-).
code = '''\
for i in range(10):
print(i)
'''
can also be rewritten, for instance,
code = ("for i in range(10):\n"
" print(i)")
perhaps with more ignored newlines added.
Yeah, true as far as it goes.
As I mentioned, I personally tend to use a flavour of dedent which
strips the first line and dedents the rest, and the example docstring I
showed doesn’t acquire a leading newline; the dedentish function I use
exists so that I don’t need reach for things like the backslash.
Yes, but that requires adding a lot more noise to a piece of text I would rather be able to copy and paste into an editor and be done with.