[throwaway43234]

I understand that this is standard practice by now, but this is one of those cases where I can't help but feel the language design team strayed too far from the original spirit of python. Now there's yet another possible interpretation of an asterisk: multiplication; splatting; exponentiation; declaring variadic arguments; and now declaring that all subsequently declared arguments are to be keyword-only. And I understand that it sort-of relates to declaring variadic arguments, but it certainly isn't declaring variadic arguments, and in my opinion reusing the same token in the same syntactic construct for two wildly different purposes is destined to cause confusion. For evidence, see the other replies: people don't know about this and can't easily tell what it does. This runs counter to the Zen: "Readability counts", "Explicit is better than implicit", "Special cases aren't special enough to break the rules.", etc.

I think JavaScript got this right where the semantic resolution steps of arguments pretty closely follow the steps for assignment, which means once someone understands the basic idea of object destructuring they get named arguments for free, in the form of destructured object parameters:

    const foo = (positionalArg1, {namedArg1, namedArg2 = 'foo'}) => { ... }
    foo(1, {namedArg: 'bar'}) 
    // resolved same as 
    const [positionalArg1, {namedArg, namedArg2 = 'foo'}] = [1, {namedArg: 'bar'}]

[kabacha]

I'll disagree with you here. In Python `*` is already a extremely popular symbol for expanding and there's no usage conflict between expand and numeric multiplication. This change gels really nicely with the rest of expand ecosystem.

I think it's much more beautiful and convenient than your JS example which in all honesty looks necessary cluttered and ugly.

[jakear]

But there’s no expanding happening here? So why take a token that’s immediately recognizable as either “expanding” or “muliplying-ish” and extend it to mean “or enforcing named parameters and not expanding”?

> cluttered and ugly

I won’t argue with you about visuals because I don’t think they’re all that important. But, I think it’s undeniable that reusing the same syntactic concepts across different semantic use cases is quite a lot more logically clean & beautiful than introducing new syntax that other HN commenters with past python experience can’t even understand. If someone sees the JS named parameter syntax at a declaration and has any JS experience, they’ll almost certainly figure out what to do - if someone sees the asterisk, even with Python experience, they’ll think “what the heck is this asterisk?” And again, the other commenters on this thread are clear evidence that this is indeed as unintuitive as I describe.

[masklinn]

> But there’s no expanding happening here?

There's a collection of 0 arguments. the "∗" was introduced specifically as a shortcut for:

    def foo(a, *ignore, b):
        if ignore:
            raise TypeError

forgoing the name simply signals to the language that it should collect nothing.

It's a logical extension of the assumption that anything which follows `∗arg` is a keyword-only parameter.

[jessedhillon]

    *args

creates a catch-all variadic function parameter called `args` which matches all positional parameters not heretofore assigned

    *

(same operator, without a name following) indicates that no more positional parameters may be matched after this point

They are close enough cognitively to warrant reuse IMO.

[dragonwriter]

> This runs counter to the Zen: "Readability counts", "Explicit is better than implicit"

Huh? It's both making parameters more explicit and functions using it more readable and self-documenting.

In fact, the old way, before bare / and * in args list, where functions essentially had mandatory optional-keyword arguments made every function create an API in violation of “There should be one-- and preferably only one --obvious way to do it.”

[jakear]

I’m not interested in comparing it to the old way, that’s saying “this unintuitive way of doing things is a better way of doing them than before when they were impossible”. Achieving that is a too low a bar to be worth discussing.

It is very much not readable, as evidenced by the other python-experienced commenters on this thread having no clue what it means (“readability” doesn’t mean “easy to understand for people who already know what it means”, as achieving that is a very low bar. What should be targeted is “obvious enough to have a clear meaning even to those who haven’t studied the exact section of the spec”, which is possible in the JS approach as they’re reusing the same syntactic constructs throughout the language, but is impossible in the Python approach because they introduce new syntax to work around every little limitation of their existing syntax)

[_ZeD_]

Passing an object to a function call, at best, can be described as a workaround.

Named argument are more explicit.

I wrote a lot of old python and js code with dict/object as argument, they were dreadful