On 25/06/13 03:58, Andrew McNabb wrote:
I'm not even sure I like it, but many of the responses have denied the existence of the use case rather than criticizing the solution.
I haven't seen anyone deny that it is possible to write code like spam(ham=ham, eggs=eggs, toast=toast) What I've seen is people deny that it happens *often enough* to deserve dedicated syntax to "fix" it. (I use scare quotes here because I don't actually think that repeating the name that way is a problem that needs fixing.) People have criticized the solution, for its lack of explicitness, for being focused on such a narrow special case, for its (subjective) ugliness, and for its fragility. Refactoring a variable name shouldn't require you to change the way you pass it to a function, but with this proposal, it does. If you refactor the name "ham" to "spam" in func(=ham, eggs=SCRAMBLED, toast=None, coffee='white') you also need to change the implicit keyword syntax back to ordinary explicit keyword syntax, or it will break. (Worse than breaking, if func happens to have a parameter "spam" as well, it will silently do the wrong thing.) That's a "feature smell", like a code smell but for features. I cannot think of any other feature, in any other language, where changing a variable's name requires you to change the syntax you can use on it. The OP seems to believe that the existence of an occasional function call with a spam=spam parameter is a major factor in discouraging the use of keyword arguments everywhere. I do not believe this is the case, but even if it were, I say, oh well. We shouldn't want keyword arguments *everywhere*, but only where they add clarity rather than mere verbosity. -- Steven