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

[Steven D'Aprano]

On Tue, Jun 25, 2013 at 12:40:34PM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >If you refactor the name "ham" to "spam" in
> >
> >func(=ham, eggs=SCRAMBLED, toast=None, coffee='white')
> >
> >you also need to change the implicit keyword syntax back to ordinary 
> >explicit keyword syntax, or it will break.
> 
> I don't see that as a major problem. If you change the name
> of a keyword argument, you have to review all the places it's
> used anyway.

I'm not talking about changing the name of the parameter, I'm talking 
about changing the name of the argument passed to the function. That is, 
the "ham" on the *right* of ham=ham, not the left.

Of course, it takes far more faith in refactoring tools than I have to 
blindly run an automated tool over code changing names. But even if you 
review the code, it's very easy to miss that =ham was valid but after 
refactoring =spam is not.

Whereas the explicit func(ham=ham) => func(ham=spam) continues to work 
perfectly. This proposed change leads to fragile code, where a trivial 
renaming will break function calls.


> > I cannot think of any other feature, in any other language,
> >where changing a variable's name requires you to change the syntax you 
> >can use on it.
> 
> That can happen already. If you're accepting a ** argument
> and passing it on, and the names change in such a way that
> the incoming and outgoing names no longer match, that whole
> strategy will stop working. 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*. 

func(a, b, c, **kwargs)

keeps the same syntax, whether you refactor the name "kwargs" to "kw" or 
"extras" or any other name, or whatever you do to the keys inside it. 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.

Wait, no, I have just thought of one: the magic treatment of super() 
inside methods in Python 3:

    def method(self, arg):
        super().method(arg)  # works
        s = super; s().method(arg)  # doesn't work

But that's arguably because super() actually should be a keyword rather 
than just a regular builtin. In any case, I don't think that super() is 
a precedent for this proposal.


> >We shouldn't want keyword arguments *everywhere*, but only where 
> > they add clarity rather than mere verbosity.
> 
> I agree that wanting to using keyword arguments everywhere
> is excessive. But I do sympathise with the desire to improve
> DRY in this area. While the actual number of occasions I've
> encountered this sort of thing mightn't be very high, they
> stick in my mind as being particularly annoying.

I really wish people would stop referring to every trivially repeated 
token as "DRY". It is not.

x = a + b + c

Oh noes! Two plus signs! It's a DRY violation! Not.

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.

"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. It's 
no more of a DRY violation than "spam = -spam" would be.


-- 
Steven