[Python-ideas] Keyword only argument on function call

[Anders Hovmöller]

On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano wrote:
>
> On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote: 
>
> > I have a working implementation for a new syntax which would make 
> > using keyword arguments a lot nicer. Wouldn't it be awesome if instead 
> > of: 
> > 
> >         foo(a=a, b=b, c=c, d=3, e=e) 
> > 
> > we could just write: 
> > 
> >         foo(*, a, b, c, d=3, e) 
> > 
> > and it would mean the exact same thing? 
>
> No.


Heh. I did expect the first mail to be uncivil :P
 

>  
>

> > This would not just be shorter but would create an incentive for 
> > consistent naming across the code base. 
>
> You say that as if consistent naming is *in and of itself* a good thing, 
> merely because it is consistent. 
>

If it's the same thing yes. Otherwise no.
 

> I'm in favour of consistent naming when it helps the code, when the 
> names are clear and relevant. 


Which is what I'm saying.
 

> But why should I feel bad about failing to 
> use the same names as the functions I call? 


Yea, why would you feel bad? If you should have different names, then do. 
Of course.
 

> If some library author names 
> the parameter to a function "a", why should I be encouraged to use 
> that same name *just for the sake of consistency*? 
>

It would encourage library authors to name their parameters well. It 
wouldn't do anything else.
 

> > So the idea is to generalize the * keyword only marker from function 
> > to also have the same meaning at the call site: everything after * is 
> > a kwarg. With this feature we can now simplify keyword arguments 
> > making them more readable and concise. (This syntax does not conflict 
> > with existing Python code.) 
>
> It's certainly more concise, provided those named variables already 
> exist, but how often does that happen? You say 30% in your code base. 
>

(Caveat: 30% of the cases where my super simple and stupid tool can find.)

It's similar for django btw. 
 

> I disagree that f(*, page) is more readable than an explicit named 
> keyword argument f(page=page). 
>

People prefer f(page) today. For some reason. That might refute your 
statement or not, depending on why they do it.
 

>
> My own feeling is that this feature would encourage what I consider a 
> code-smell: function calls requiring large numbers of arguments. Your 
> argument about being concise makes a certain amount of sense if you are 
> frequently making calls like this: 
>

I don't see how that's relevant (or true, but let's stick with relevant). 
There are actual APIs that have lots of arguments. GUI toolkits are a great 
example. Another great example is to send a context dict to a template 
engine. 

To get benefit from your syntax, I would need to 
> extract out the arguments into temporary variables: 
> which completely cancels out the "conciseness" argument. 
>
>     First version, with in-place arguments: 
>         1 statement 
>         2 lines 
>         120 characters including whitespace 
>
>     Second version, with temporary variables: 
>         3 statements 
>         3 lines 
>         138 characters including whitespace 
>
>
> However you look at it, it's longer and less concise if you have to 
> create temporary variables to make use of this feature. 


Ok. Sure, but that's a straw man....

/ Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180906/61521f40/attachment.html>