[Python-ideas] Keyword only argument on function call

[Calvin Spealman]

On Thu, Sep 6, 2018 at 9:11 AM Steven D'Aprano <steve at pearwood.info> 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.
>
>
> > 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.
>
> I'm in favour of consistent naming when it helps the code, when the
> names are clear and relevant. But why should I feel bad about failing to
> use the same names as the functions I call? 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*?
>

I've been asking this same question on the Javascript/ES6 side of my work
ever since unpacking was introduced there which baked hash-lookup into
the unpacking at a syntax level.

In that world its impacted this same encouragement of "consistency" between
local variable names and parameters of called functions and it certainly
seems
popular in that ecosystem. The practice still feels weird to me and I'm on
the fence
about it.

Although, to be honest, I'm definitely leaning towards the "No, actually,
it is a
good thing." I grew up, development-speaking, in the Python world with a
strong emphasis drilled into me that style constraints make better code and
maybe this is just an extension of that.

Of course, you might not always want the same name, but it is only
encouraged
not required. You can always rename variables.

That said... I'm not actually a fan of the specific suggested syntax:

>  foo(*, a, b, c, d=3, e)

I just wanted to give my two cents on the name consistency issue.



> > 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.
>
> (By the way, well done for writing an analysis tool! I mean it, I'm not
> being sarcastic. We should have more of those.)
>
> I disagree that f(*, page) is more readable than an explicit named
> keyword argument f(page=page).
>
> 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:
>
> # chosing a real function, not a made-up example
> open(file, mode=mode, buffering=buffering, encoding=encoding,
>      errors=errors, newline=newline, closefd=closefd, opener=opener)
>
> If 30% of your function calls look like that, I consider it a
> code-smell.
>
> The benefit is a lot smaller if your function calls look more like this:
>
> open(file, encoding=encoding)
>
> and even less here:
>
> open(file, 'r', encoding=self.encoding or self.default_encoding,
>      errors=self.errors or self.default_error_handler)
>
> for example. To get benefit from your syntax, I would need to
> extract out the arguments into temporary variables:
>
> encoding = self.encoding or self.default_encoding
> errors = self.errors or self.default_error_handler
> open(file, 'r', *, encoding, errors)
>
> 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.
>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180906/cdc7a9b6/attachment-0001.html>