
By the way Anders, you're dropping attribution of the person you are quoting. That's a little impolite and makes it hard to know who said what when. On Tue, Jun 25, 2013 at 10:58:45AM +0200, Anders Hovmöller wrote:
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.
I agree with everything except the part of the last sentence after the comma where you misrepresent the entire issue at hand. Again.
I'm not misrepresenting anything. I'm making a statement that, in my judgement, your proposal for implicit parameter names has no advantage except that you sometimes get to type less. You might not accept my judgement on this, but it is an honest one.
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:
Again you're conflating my suggested syntax with the underlying idea. The syntax could be "$foo" instead of "=foo" for example.
I don't think I should be judged badly for responding to your actual proposal instead of the infinite number of things you might have proposed but didn't. [...]
It's less explicit.
You mean "more". It's absolutely more explicit than just using the position.
I'm not comparing it to positional arguments. I'm comparing: func(spam=spam) # parameter name is explicitly given func(=spam) # parameter name is implicit
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?
It's so special because one can be derived from the other. Which is impossible in all the other cases.
That's incorrect. We could run wild with implied parameters, if we so cared: funct(=3*spam, =eggs+1, =cheese[0]) could be expanded to funct(spam=3*spam, eggs=eggs+1, cheese=cheese[0]) according to the rule, "if an an argument consists of an expression with exactly one name, then the parameter name is derived from that name". I'm not suggesting this as a good idea. I think it is a terrible idea. But it is conceivable that some language might derive parameter names from expressions that are more complex than a single name I believe that it's a bad idea even if the parameter is derived from a single name.
The point isn't that it's hard to make that edit. The point is that I shouldn't need to make that edit.
If you use the alternative of **locals() suggested as an alternative you're in tons and tons more trouble than just having to make that edit.
Why would I do that? Unless I knew the called function would silently ignore unrecognised keyword args, I wouldn't use the **locals() trick. And even if I did, I probably wouldn't use the trick anyway. -- Steven