I think the biggest reason why that ends up being a pain in other languages is how the it is implemented
Instead of doing one parse for the comments, then inspecting the multi line comment counter to see if it reached 0 at the end. And if not throwing an error “you missed an end commment”
They try to comment out as much as they can and then pass what’s left to the tokeniser which then will complain about the syntax being wrong without any hint to the comment causing it
Unless you’re using a simple text editor, manually prepending # hasn’t been a thing for years. Practically every IDE has a keybind to comment arbitrary blocks of code. I’ve never felt that python’s single line comment is limiting me in any shape or form.
Agreed
This is pointless to add, as has been noted pretty much every editor makes this trivial.
As you say, this is tricky. And also mostly unnecessary. If you want to comment out code, it’s easy enough to duplicate the line, comment out the original, and edit the replacement:
# if a == b and c == d:
if a == b:
I very rarely find it beneficial to comment out code, but when I do, I find this clearer than the C-style “comment part of an expression out” form:
if a == b /* and c == d */:
Yes, this is something that’s missing from Python. But it’s not a particular major omission, and the arguments for adding it are weak compared to the disruption it would cause (to training materials, editors, linters, formatters, syntax highlighters, …)
-1 from me for adding this.
In C you can do all 3 things:
#include <stdio.h>
#if 0
int main() {
#if 0
/* The code below will print the words Hello World!
to the screen, and it is amazing */
printf("Hello" /*+ " World"*/ + "!");
#endif
return 0;
}
#endif
Here’s the best you can do in Python (fairly readable in my opinion):
if False:
def main():
if False:
"""
The code below will print the words Hello World!
to the screen, and it is amazing
"""
# print("Hello, world!")
print("Hello!")
if __name__ == "__main__":
main()
Disabling code only works because C has no multi-line string which can contain the end delimiter. In Python we can use a regular if though and every code editor can indent multiple lines.
Having c-style multi-line comments, but not c-style single-line comments would be confusing, so it would be better to use something else (but not string syntax…).
Can we add a future to make people stop complaining about it like braces?
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
>>> from __future__ import block_comments
File "<stdin>", line 1
SyntaxError: just add '#' before every line
I don’t think that’s accurate. /* is pretty commonly used in interacting with directories, e.g. os.system('ls /etc/*').
The idea is not to make it impossible to put in a string but to make it improbable that it will unintentionally make its way into a string. Same response to @Nineteendo, by the way.
What I’m saying is that that is an impossible goal. The moment you define a character sequence as the start of a comment, it becomes relevant, and will therefore have a reason to appear in a string literal. It will not be “improbable”.
This is fundamental and inescapable. If you do not understand this, there is no point discussing.
An even bigger problem is code with block comments, which can’t be disabled properly using block comments (macro’s handle this just fine):
#include <stdio.h>
/*
int main() {
/*
/* The code below will print the words Hello World!
to the screen, and it is amazing */
printf("Hello" /*+ " World"*/ + "!");
*/
return 0;
}
/*
And if you allow block comments to be nested, you still have the problem with them appearing in strings. Offering a flawed solution like this just isn’t going to cut it, Python is a mature language.
I see a better path forward to allow disabling code with syntactic macro’s:
if! False:
print("Hello, world!")
Just to show how multi-line comments can be super painful too:
[data-md-color-scheme="slate"] {
--doc-symbol-parameter-fg-color: #829bd1;
--doc-symbol-parameter-bg-color: #829bd11a;
}
I comment the third line with my editor shortcut:
[data-md-color-scheme="slate"] {
--doc-symbol-parameter-fg-color: #829bd1;
/* --doc-symbol-parameter-bg-color: #829bd11a; */
}
Then I comment the whole block, because reasons:
/* [data-md-color-scheme="slate"] {
--doc-symbol-parameter-fg-color: #829bd1;
/* --doc-symbol-parameter-bg-color: #829bd11a; */
} */
It’s a syntax error.
Essentially, you cannot comment/uncomment a bunch of consecutive line without first having to uncomment previously commented overlapping lines.
[data-md-color-scheme="default"] {
--doc-symbol-parameter-fg-color: #829bd1;
--doc-symbol-parameter-bg-color: #829bd11a;
}
[data-md-color-scheme="slate"] {
--doc-symbol-parameter-fg-color: #829bd1;
--doc-symbol-parameter-bg-color: #829bd11a;
}
I’ll comment the middle:
[data-md-color-scheme="default"] {
--doc-symbol-parameter-fg-color: #829bd1;
/* --doc-symbol-parameter-bg-color: #829bd11a;
}
[data-md-color-scheme="slate"] {
--doc-symbol-parameter-fg-color: #829bd1; */
--doc-symbol-parameter-bg-color: #829bd11a;
}
Now for some reason I want to overwrite the first --doc-symbol-parameter-fg-color with the second, so I uncomment this line only:
[data-md-color-scheme="default"] {
--doc-symbol-parameter-fg-color: #829bd1;
/* --doc-symbol-parameter-bg-color: #829bd11a;
}
[data-md-color-scheme="slate"] {
/* --doc-symbol-parameter-fg-color: #829bd1; */ */
--doc-symbol-parameter-bg-color: #829bd11a;
}
Doesn’t work, it was commented a second time. I have to uncomment the whole thing, then recomment the 2nd-to-6th or 3rd-to-6th lines again.
Now yes, editors could be smart about it, and use the embedded-comment syntax when commenting a selection on a single line, and use single-line comment syntax when there’s no selection (comment line where the cursor is), or when the selection spans multiple lines, or when there are multiple cursors. So, just my 2 cents 