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.
 
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. This has the advantage that it'd be the same in a dict: "{$foo}", but it has the disadvantage of not being similar to the existing syntax. Again, the idea itself is a separate thing from the syntax I spent literally 2 seconds to come up with :P
 
It's less explicit.

You mean "more". It's absolutely more explicit than just using the position. 
 
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. 
 
Even if it is special, it's not special *enough* to justify special
syntax.

In your opinion. In my opinion we could have an open ended brain storm about these types of things, and we can acknowledge that it's a matter of trade offs. 


Either I'm not explaining myself, or you're not understanding me. Let me
give you some examples.

He was using your hyperbole against you :P
 
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. Or even worse with the _() magic that goes through the stack and digs out the locals. *shudder*

I understand you don't like my suggestion, but I hope we can both agree that locals() for anything but a string formatter with a literal, or rummaging through the stack is much much worse?
 
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".

Words are defined not by dictionaries but by how they are used. Words change meaning over time. 
 
> 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"?
 
Again with the straw man. That wasn't what he said. He said that if 'personal_name' is *a better name for what it actually is* then it is a good idea to change it in the entire code base. It's always a good idea to make the names of stuff in your code better. This has nothing to do with this thread though!