On Tue, Jun 25, 2013 at 06:47:57PM +1200, Greg Ewing wrote:
Steven D'Aprano wrote:
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*.
It's still a bigger change than any automated tool will be able to cope with, and if you're changing it manually, who cares if the syntax changes or not?
Because having to change the syntax is *one more thing* to worry about when you change a variable name, or change a parameter. Because forgetting to change the syntax is *one more thing* to go wrong. This makes this proposed feature *more* fragile rather than less, and I don't think we should be adding syntax that encourages fragile code for marginal benefit, particularly when the proposal goes against two of the Zen and, frankly, has nothing much going for it except a little less typing in a fraction of all function calls. It doesn't make code more readable, except in the sense that there's less to read. If anything, it's *less* readable because it looks like you've forgotten the parameter name: func(a, b, spam=None, ham="green", =eggs, extra=False, another=42*x) It's less explicit. It priviledges a special case that really isn't that important. Out of the infinite number of possible combinations of parameter=expression, what's so special about the one where the expression happens to be precisely the same string as the parameter? Even if it is special, it's not special *enough* to justify special syntax.
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.
Pardon? *Every* time you use a name, you're relying on it being the same as at least one other name somewhere else.
Either I'm not explaining myself, or you're not understanding me. Let me give you some examples. "x = 2*y", if I rename y => z the statement remains "x = 2*z", I don't have to change it to "x = x.__mul__(z)". "mylist.append(None)", if I rename mylist => alist the statement remains "alist.append(None), I don't have to change it to "alist.extend([None])". "if seq:", if I rename seq => items the statement remains "if items:", I don't have to change it to "if bool(items):". BUT the proposed syntax is different from everything else in Python: "func(=spam)", but if I rename spam => ham, I must also change the way I call the function to "func(spam=ham)". The point isn't that it's hard to make that edit. The point is that I shouldn't need to make that edit.
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.
You seem to think I'm using a form of argument by authority: "It's DRY, therefore it's undesirable." But that's not what I'm saying. Rather, I'm saying that I feel it's undesirable, and I'm using the term DRY to *describe* what I think is undesirable about it. Maybe I'm not using the term quite the way it was originally meant, but that has no bearing on how I feel about the matter and my reasons for it.
This isn't a question of "original meaning", you are misusing DRY to describe something which has nothing to do with the principles behind DRY, also known as "Single Point of Truth". You might as well describe your dislike of func(spam=spam) as "a violation of the Liskov Substitution Principle", then say "well that's not what Barbara Liskov meant by the LSP, but it's what I mean". I'm sorry if it annoys you to be told that your understanding of Don't Repeat Yourself is mistaken, but it is. It is not "any repetition of code is a bad thing".
"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.
I'm not so sure about that. I've just been watching this:
http://pyvideo.org/video/1676/the-naming-of-ducks-where-dynamic-types-meet-s...
and going by the principles advocated there, if you change the name of the parameter in the called function, you *should* change the corresponding parameter of your function to match, for the sake of consistency.
The called function may be called from a thousand places. Do you really think that because I decide I don't like my local variable to be called (say) "first_name", and want to call it "personal_name" instead, that I "should" force every other caller to change their local variable too, "for the sake of consistency"? I'm sure you know the proverb about foolish consistency. -- Steven