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

[Andrew Barnert]

On Jun 24, 2013, at 18:22, MRAB <python at mrabarnett.plus.com> wrote:

> On 25/06/2013 01:58, Andrew Barnert wrote:
>> From: Greg Ewing <greg.ewing at canterbury.ac.nz>
>> 
>> Sent: Monday, June 24, 2013 4:49 PM
>> 
>> 
>>> Andrew Barnert wrote:
>>>> On Jun 23, 2013, at 16:34, Greg Ewing <greg.ewing at canterbury.ac.nz>
>>> wrote:
>>>> 
>>>>> It occurs more often than you might think, because taking
>>>>> parameters that you've been passed and passing them on to
>>>>> another function is a common pattern
>>>> 
>>>> Yes, I do that all the time. But I can't think of a single case where
>>>> there's any benefit to using keyword arguments.
>>> 
>>> That's puzzling, because the benefits are the same as with
>>> any other call that benefits from keyword arguments.
>> 
>> No they aren't.
>> 
>> The main benefit that a call gets from keyword arguments is that, from the parameter names, you can tell what the arguments mean.
>> 
>> When the arguments are already variables (parameters or locals) with the same name, you already have the same information, and there is no benefit from getting it twice.
>> 
>> Compare:
>> 
>>     url = get_appdir_url(False, None, True)
>>     url = get_appdir_url(per_user=False, for_domain=None, create=True)
>> 
>> This is a change I made earlier today in someone else's coded. The improvement is, I hope, unarguable.
>> 
>> But here's another function call I _didn't_ change:
>> 
>>     def get_appdir_url(per_user, for_domain, create):
>>         return get_special_url('appdir', per_user, for_domain, create)
>> 
>> Would this be at all improved by adding keywords?
>> 
>>         return get_special_url(special='appdir', per_user=per_user, for_domain=for_domain, create=create)
>> 
>> That just adds noise, making it less readable, rather than more.
>> 
>> Of course there's another benefit: Sometimes, using keywords lets you reorder the arguments to a way that makes more sense for your use case and/or skip defaulted parameters that you don't care about:
>> 
>>     gzip.GzipFile(fileobj=f, compressionlevel=1)
>> 
>> Obviously, I'm all for using the keywords there as well. But the proposal doesn't affect cases like that.
>> 
>>> Do you doubt the usefulness of keyword arguments in general?
>> 
>> Not at all. I only doubt the idea of encouraging people to use keyword arguments _everywhere_.
>> 
>> Keywords make code more readable in some. cases, less readable in others. Blindly using keywords everywhere would make code overall less readable, just as blindly avoiding keywords everywhere.
>> 
>> Most Python programmers today seem to do a decent job finding the right balance, and the language and library do a decent job helping them. Could that be better? Sure. But encouraging keywords everywhere would not make it better.
>> 
>> And a proposal that's specifically intended to encourage using keywords in cases where they add nothing but noise would definitely not make it better.
>> 
>> I've already granted that dict construction is a special case where this may not be true. (When is dict construction not a special case when it comes to keyword arguments?) But, as I said before, I don't think it's the right solution for that case—and, since then, at least two people have offered other ideas for that special case.
> Why not just add a single marker followed by the names, something like this:
> 
>    return get_special_url(special='appdir', =, per_user, for_domain, create)

That's less ugly, but I still don't see what the benefit is. The code that already works in Python 3.3 (and even 2.x) has the same amount of information (again, it's already obvious what the parameters mean without using keywords), and it's even less ugly, and it doesn't require any new syntax.

I suppose if someone later reorders the parameters of get_special_url without making any other change to the API, my code will still work. But how often does that happen? And I'm not sure a language change that encourages such API changes is a good thing.