Pretty sure you mean to use the and operator instead in order for the expression to evaluate as d.
Your trick wouldn’t work for keyword arguments though:
foo(a, #_option1=True, option2=3)
And with your trick requiring that many keystrokes I would just use my good old trick of hitting Enter and commenting out the individual argument, positional or not:
foo(a,
#b,
c, d)
A few more keystrokes required but indeed still quite workable, and better than having to scroll to the end of a code block with the docstring approach I usually take when working in an editor without support for block commenting:
'''
def vec_add(
x,
y
):
"double-quoted docstring"
....
'''
Most production systems only have the most basic editors installed. This feature would’ve (however slightly) benefitted our operations team on several occasions when a critical error occurred on a production system where it was painfully obvious what a quick fix in code could be to immediately stop the bleed, where every keystroke and mouse movement counts in a race against time.
To really know the benefit you’d have to estimate how many esoteric bugs they would introduce with this as well.
Yes, of course it is only meant for an obvious quick fix from an on-call operations team member. A full post mortem and due review process will always follow.
Not that I can think of. I wasn’t trying to defend that syntax, I just meant “yeah it would be cool”.
Yeah, I just doubt it’s worth adding a footgun even if everyone promises to use it responsibly.
Acknowledging that the programming domains I’ve worked in may be rather niche, I recall commenting out parameters in some cases:
def jit_inline_fun(a: int, b: int, c: int):
...
where jit_inline_fun is jit compiled and then inlined.
So a call site like this:
result = jit_inline_fun(foo, bar, baz)
may end up calling into a module that is implemented in C, which will evaluate the JIT’d function. The delegation may have some embedded checks based on the declared types of the params.
So, a misalignment in the declaration of the parameter types (e.g. what should be “i32,i32,i32” is misdeclared as “*i32,…”) perhaps leads to an error, but the error might not clearly represent the problem in a manner recognizable to a user of the library, other than that a parameter is causing an issue.
In those cases I’ve found that commenting out a parameter can quickly resolve which param has an issue, where otherwise it can be very difficult to localize the problem, as errors are not always very interpretable.
Other cases that haven’t been addressed here are e.g. function invocations spread over multiple lines.
A multiline function call (or any simple statement) can be “commented out” with the if 0: trick:
if 0: value = foo(
a,
b
)
Oh. If this is your proposal then you are going to need a much more rigorous definition of “structure”, at minimum.
But if (#_a, b), by itself rather than as function arguments, becomes (b), then suddenly a tuple has turned into a parenthesized value.
If something this trivial needs to be addressed in production, your organization needs better code review and deployment processes, not a change to Python’s grammar.
The best designed and reviewed code can have bugs.
But i do not think this change will help.
There are better ways to test changes in a production environment.