If I’m not mistaken, the second line will undo the effect of the first line, no? If you want to manipulate lines with sed, you should use markers in your comments:
That looks quite confusing to read. You need to take notice of exactly
how many #s there are to tell which parts are active. – but only on
lines where the # is followed by “”". No longer can you just skim and
ignore any line that starts with #.
Also it’s rather specialised, allowing you to toggle between 2 versions,
but not choose one of 3 or more.
def verify(filename, clear_payload):
#"""
# I would like to verify if the PNG is valid and not corrupt but Pillow .verify() is not yet implemented
im = Image.open(filename)
im.verify()
im.close()
#"""
content = open(filename, "rb").read()
This is actually not a totally uncommon pattern; the code snippet can be “deactivated” by one keystroke:
def verify(filename, clear_payload):
"""
# I would like to verify if the PNG is valid and not corrupt but Pillow .verify() is not yet implemented
im = Image.open(filename)
im.verify()
im.close()
#"""
content = open(filename, "rb").read()
This turns these few lines into a multi-line string literal that is just discarded. This construct can be (ab)used as a multi-line comment. (In this particular case, it is a doc string, but maybe the author did not care about this.)
I don’t see what’s so anti-Python about /* */ when Python already borrowed a good number of syntaxes from C++. To me that’s the most natural choice if we are to add a multiline comment syntax to Python. The fact that it’s an outright invalid syntax in Python today also makes it more viable than your proposed syntax.
Here is a related idea. I find the following more useful than a proposed comment block alone, but I probably wouldn’t propose it outside of this topic.
triple quoted h-string (Inspired by shell heredoc):
h"""somename
# this string can contain other triple-quote strings
# because its endquote is marked with 'somename'
def commented_out_function():
"""
docstring
"""
return
"""somename
n-string (noop)
It’s a string that is thrown away by the parser and because of that it doesn’t have
to follow indentation rules.
def func(a, b):
x = a * b
n"""
# I'm not here, this is not happening
print(a, b, x)
"""
Each of them could be sometimes useful on its own. And combined into a nh-string they form a universal comment block.
Only problem is that >>> is used in docstrings to indicate the REPL. If tools then evaluate the code in a docstring (which a few testing tools do), that would likely raise a syntax error, resulting in breaking tests?!
I like the heredoc string. It is loosely reminiscent of Rust raw string literals, but much more readable because the delimiters are on their own lines and can serve a documentation purpose like a small comment already. Maybe you can propose it in a separate thread.
While I do share the belief that “the juice isn’t worth the squeeze”, I also understand the opposite perspective because it’s one that was expressed more explicitly when I was practically subscribed to the RFCs repo in Rust’s early days.
In essence, design your language on the assumption that the user will be using something like notepad.exe so IDE/programmer’s text editor features have a high baseline to improve on.
There is some validity to this. However, I don’t really see a problem with the status quo for that. Yes, if you’re in Notepad, you have to press #, down, left, #, down, left, until you get every line commented out. That’s the baseline that even a basic text editor can easily improve on, but it’s also a baseline that is entirely workable (I’ve done the exact same thing for bulk edits in myriad contexts).
In greenfield design, I’d say that having a multi-line comment syntax like /* */ becomes more valuable the longer the span you want to comment out. However, In this context, I’ll restate that I don’t think “the juice is worth the squeeze” for adding a new syntax… especially when multi-line strings can be abused as multi-line comments.
Yes, but also, it quickly gets to the problem of nesting. Most languages do not allow those comments to be nested; which means, if you’re commenting out a large block of code and it happens to contain another /* */ comment, the comment stops short.
(And if they CAN be nested, you have to be paranoid about having those characters together inside a quoted string, lest you get the opposite problem.)
I don’t particularly like block comments and avoid using them in languages where they are available, because they “broke” my greps.
If I search (with grep or my IDE) for something (like a function invocation) it’s very easy to detect lines that are commented out wth ‘#’ (or ‘//’ or ‘–’).
it’s a bit more cumbersome with block comments, as I need to open the file and look for the context to understand if it’s “actual” code or not.
Your repository doesn’t answer any of the pressing questions (backwards incompatibility for one) but is instead an unconvincing AI-generated pitch of your idea. It would be great if you showed that your idea is unequivocally better than what IDEs can already do and found a way to mitigate the change breaking currently valid code first.