[Python-ideas] Short form for keyword arguments and dicts
Steven D'Aprano
steve at pearwood.info
Tue Jun 25 12:16:51 CEST 2013
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
More information about the Python-ideas
mailing list