On Tue, Jun 25, 2013 at 12:40:34PM +1200, Greg Ewing wrote:
Steven D'Aprano wrote:
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.
I don't see that as a major problem. If you change the name of a keyword argument, you have to review all the places it's used anyway.
I'm not talking about changing the name of the parameter, I'm talking about changing the name of the argument passed to the function. That is, the "ham" on the *right* of ham=ham, not the left. Of course, it takes far more faith in refactoring tools than I have to blindly run an automated tool over code changing names. But even if you review the code, it's very easy to miss that =ham was valid but after refactoring =spam is not. Whereas the explicit func(ham=ham) => func(ham=spam) continues to work perfectly. This proposed change leads to fragile code, where a trivial renaming will break function calls.
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.
That can happen already. If you're accepting a ** argument and passing it on, and the names change in such a way that the incoming and outgoing names no longer match, that whole strategy will stop working. The change required in that case is much bigger than just replacing '=foo' with 'foo=blarg'.
But you don't have to change the *syntax*. func(a, b, c, **kwargs) keeps the same syntax, whether you refactor the name "kwargs" to "kw" or "extras" or any other name, or whatever you do to the keys inside it. I cannot think of any other syntax, certainly not in Python, which relies on a name being precisely one value rather than another in order to work. Wait, no, I have just thought of one: the magic treatment of super() inside methods in Python 3: def method(self, arg): super().method(arg) # works s = super; s().method(arg) # doesn't work But that's arguably because super() actually should be a keyword rather than just a regular builtin. In any case, I don't think that super() is a precedent for this proposal.
We shouldn't want keyword arguments *everywhere*, but only where they add clarity rather than mere verbosity.
I agree that wanting to using keyword arguments everywhere is excessive. But I do sympathise with the desire to improve DRY in this area. While the actual number of occasions I've encountered this sort of thing mightn't be very high, they stick in my mind as being particularly annoying.
I really wish people would stop referring to every trivially repeated token as "DRY". It is not. x = a + b + c Oh noes! Two plus signs! It's a DRY violation! Not. I exaggerate a little for effect, but it really does seem that many people think that any piece of code, no matter how trivially small, that is repeated is a DRY violation. But that's not what DRY is about. "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." https://en.wikipedia.org/wiki/Don%27t_Repeat_Yourself which has nothing to do with writing spam=spam in a function call. It's no more of a DRY violation than "spam = -spam" would be. -- Steven