Python should allow comments AFTER continuation line bar

I think it is too strict from python not allowing anything after ‘\’ because spaces, tabs or even comments could be ignored by Python after this bar, and cleaned at compiling time. Simple because they are not “code”, just comments, and in the case of spaces and tabs, formatting for comments to be clear

It is like a client saying: “The chicken is bad in this resturant”. Instead of them look and try to modify the chicken recipe ( my first intent), they say: eat pork and leave the chiken.

Changing the bars behavior is an improvement for Python. Spaces and comments should be allowed at right of ‘\’

Just need at compile time, to remove all after ‘\’ until next newline ‘\n’

Well, it’s like one person barging in to a restaurant and saying “I don’t like the chicken!” while a million other people are happily eating the chicken with no problems. :joy:

You’ll need to provide a lot more justification than “I want this”. This change would require modifying the parser, and making sure that nothing breaks. Is there a benefit beyond a tiny amount of convenience for a subset of users?

I never use line continuations in python, and they are removed by the most popular formatting tools. I wonder how common they are in the wild.

1 Like

Groups are just groups. If python admits ‘\’ so people might use it, even because beginners may not know the ( ) feature.

Everything is a suggestion, not because I want. I think it would be more friendly to allow comments at right.

I am sure that is simple for a compiler to do a replace '\[^\n]+\n for ‘\\n’ before compiling it.

It wouldn’t be a line continuation anymore, would it?

1 Like

It’s simple, but it would break any code with a backslash in it (i.e. print("hi\tthere"))

3 Likes

I understand now the fear. The regexp sould check also if the last ‘\’ bar is really a continuation bar and not a string character… anyway, lets leave the chicken. Thanks

1 Like

the compiler sould parse “strings” before the ‘\’ bar continuations
This way a ‘\’ inside a string would not be considered continuation bar

By the way, I like regexps. Just improving the first one:

# a \ bar followed  by any spaces, one optional # 
# followed by "not ( \ and quotations)" repeating till a final \n

'\\\\\s*(#[^\\\\"\']*)?\n$'

\ as a line continuation marker can currently keep a multi-line string a single token, so:

"hello \
world"

is really one string token.

But by allowing a comment after \:

"hello \ # comment
world"

Are you going to force it to be tokenized as 3 tokens, one string token of "hello , one comment token of # comment, and another string token of world"?

from io import StringIO
from tokenize import generate_tokens

file = StringIO(r'''"hello \
world"
''')
print(*generate_tokens(file.readline), sep='\n')

This outputs:

TokenInfo(type=3 (STRING), string='"hello \\\nworld"', start=(1, 0), end=(2, 6), line='"hello \\\nworld"\n')
TokenInfo(type=4 (NEWLINE), string='\n', start=(2, 6), end=(2, 7), line='world"\n')
TokenInfo(type=0 (ENDMARKER), string='', start=(3, 0), end=(3, 0), line='')
2 Likes

Yes you are right, many details I haven’t thought.
Maybe the ‘\’ shoul be deprecated in python, asking to use only ( )

1 Like

In the case of “hello \ #comment
world” the compiler would remove ’ #comment’ and keep as it is…

Line continuation is typically used for ease of reading long lines. If you have enough space after the backslash, you are using the backslash wrong.

2 Likes

I disagree. Line continuation allows to break the code wherever the programmer wants, maybe to separate a logic in parts.

…yes, and a logical part has no comment in it.

Let’s look at the example below:

msg = "hello \ # comment "
world"

Does it make it more readable? Or is it even parsable?

Quotations ( " ’ ) after the bar would not be allowed. The correct would be:

msg = "hello \  # comment <- without quotation after the bar
world"

So far, we have:

  1. changed the meaning of the line continuation to something else
  2. banned some characters from being used in comments

You suggest allowing comments after the backslash. The quotation mark is after the comment “#”, not after the “\”.

Also, that’s not how comments work. They are non-executable statements or annotations within the code. They don’t have any technical relation with the executable code. In other words, they are independent of the executable code.

1 Like

1- To line break
2- the chars are banned IF the comment is after the line continuation
For regular comments, (full line) no restrictions

# I am a "full" comment 'line'
if a == b and c == 1 and d >= 2.7   \  # Here I could not use quotations!

Then we will have made the rules for comments more complex. Currently the concept of a comment is elegant in its simplicity This line from the Zen should be considered:

Simple is better than complex.

1 Like