On Fri, Apr 17, 2020 at 11:57 AM Steven D'Aprano <steve@pearwood.info> wrote:
On Fri, Apr 17, 2020 at 11:25:15AM +0200, Alex Hall wrote:

> I don't think you really need to know what it means to read the code for
> most purposes.

*blink*

> You look at the function call and you can see a bunch of
> names being passed to self.do_something. If the function call has
> 'keyword=keyword' in it instead of just 'keyword', that's not adding much
> information.

Of course it adds important information! It is adding the critical
information: which parameter gets assigned the specified value.

Of course it's adding some information, but it's not information a reader usually has to think about.
 
Put yourself in the position of someone who doesn't know the meaning of
the * in a function call. What's the difference between these two calls?

    f(x)
    f(*, x)

It's not good enough to merely say that you're passing an argument `x`.
That's true of both calls. There must be a difference between the two,
otherwise why have the star?

Readers don't generally have to compare two similar looking pieces of code. If they do, it's generally in a conversation with someone
(e.g. when reviewing a PR) and they can ask that person what the asterisk means.
So "What's the difference between these two calls?" is not usually a relevant question.

Positional arguments tell us that values are assigned to parameters from
left to right:

    function(spam,  # first parameter
             eggs,  # second parameter
             cheese,  # third parameter
             )

but we have no clue at all what the names of those parameters are.
That's the down-side of positional arguments, and one of the reasons why
positional arguments don't scale. Knowing the names of the parameters is
often important.

Keyword arguments fill in the missing critical information:

    function(alpha=spam,
             beta=eggs,
             gamma=cheese,
             )

and we can shuffle the order around and the mapping of argument value to
parameter name is still clear.

That doesn't matter here because the parameter and variable names have to match to use the shortcut.
 

> The technical details of how an argument is being passed are
> usually not important to readers.

I don't care about the argument passing implementation. I care about the
meaning of the code. Here is a real-world case:

    open('example.txt', encoding, newline, errors, mode)

    open('example.txt', *, encoding, newline, errors, mode)

Would you agree that the two of those have *radically* different
meanings? The first will, if you are lucky, fail immediately; the second
may succeed. But to the poor unfortunate reader who doesn't know what
the star does, the difference is puzzling.

This holds even more strongly if the various parameters take the same
type:

    # a real signature from one of my functions
    def function(
           meta:bool,
           dunder:bool,
           private:bool,
           ignorecase:bool,
           invert:bool)

    function(dunder, invert, private, meta, ignorecase)
    function(*, dunder, invert, private, meta, ignorecase)


No reader will ever have to think about the difference. They will simply see the second version and know which arguments are being passed.
Also, your examples are clearly demonstrating that using the shortcut makes it easier to avoid mistakes.

I'm not really sure what you're actually concerned about. Can you give a hypothetical scenario explaining how someone would be confused in practice? Here's the worst case scenario I can imagine:

A reader is trying to debug some code that isn't behaving right. The call `function(*, dunder, invert, private, meta, ignorecase)` isn't doing what they expect. if they put a breakpoint or some prints inside `function` they would probably see that the variables `dunder`, `invert`, etc. have the correct/obvious values inside, but they don't. Instead they visually inspect the function call and the function definition. They don't know what '*' means, and they don't bother to find out, so they think arguments are being passed positionally. They compare the positions of the arguments and parameters in the call and definition and see they don't match, and they think that's the problem. They try to fix the call by rearranging the arguments or switching to explicit keyword arguments. That doesn't change the behaviour of the program so they spend some time being confused about that.