[Python-ideas] Short form for keyword arguments and dicts

[Steven D'Aprano]

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