Hi Joshua
The Steering Council recently discussed PEP 736 - Shorthand syntax for keyword arguments at invocation.
The SC understands the desire for a simple way to handle redundant keyword passing and how this can simplify some use cases. This PEP proposes to solve this problem with shorthand syntax, and we’re very impressed with the well-researched proposal. Although we considered that this feature could make some users’ lives easier and improve productivity, we have decided to reject the PEP.
The SC identified the following concerns:
First, the SC believes that the cost versus benefit of the new syntax does not have a high enough payoff to justify the added complexities and maintenance required from the wider Python ecosystem to support the new syntax and grammar changes. We favor readability over writability, as we know that code is typically read far more frequently than it is written. There is arguably an added cognitive lookup to “fill in the blanks” and ensure that the missing variable after the equal sign is indeed the intended behavior or a mistaken omission. Generally, modern IDEs have given us excellent tools for auto-completion and the overhead of typing (or tab-completing) a variable name seems to win out in cognitive efficiency. This would be an incredibly interesting study to prove which is actually true.
Second, we have some concerns about complicating the grammar around function arguments, since this is a particularly complex part of the language that already involves plenty of different features and is saturated with grammar paths that involve several tokens with complex ordering requirements. We also have concerns about the maintainable aspect of adding new complexity to the grammar in this particular area. This different point focuses more on the maintainability of the code and any future bug fixes and performance improvements rather than the user-visible aspects. We believe the proposal doesn’t meet the bar given these combined costs in complexity.
Third, even though it seems similar to the f-string debugging specifier, the use case is different enough that we don’t believe it can be used to draw parallels between the two and we also feel it can confuse some users.
Lastly, considering the above reasons, the SC is not convinced that this feature is the best that Python can provide. While we recognize that solutions like this can improve some use cases, they need to be properly balanced with everything else. As we have mentioned in previous occasions grammar changes are subjected to higher scrutiny levels given how far they reach.
Again, thank you for your efforts.