[nmalaguti]

While this is nice in a lot of ways, it also can make it harder for your callers to use more dynamic patterns. You can no longer call it with

    process_data(**kwargs)

and have the data field pulled out of kwargs. Of course you can still do

    data = kwargs.pop(“data”)
    process_data(data, **kwargs)

but if you are the only library doing it, it can cause things to break when it breaks programmers expectations.

[masklinn]

Not sure that's an issue, since the parameter does not have a name.

Just call it as `*args, **kwargs`. That's something you need to do when forwarding anyway.

[SethMLarson]

Yep, using positional-only parameters makes calling the API tougher when all you've got is a `**kwargs` dictionary. But I think that for well designed APIs you'll be able to avoid the scenario of "having" to pass down arguments this way.

I have an article in the earlier stages about what I call the "keyword arguments blender" and how to avoid it, I think it's a common anti-pattern in lots of Python code (including my own, guilty!)

[IshKebab]

That's a good thing! Using `kwargs` is generally a terrible idea.

[DangitBobby]

Please elaborate.

[edgyquant]

In a dynamic language it’s already hard enough determine what type a given variable is at runtime once the codebase reaches a certain size. When you’re passing arbitrary parameters in the form of kwargs that just adds another layer of dynamism on top that can make debugging even more difficult. It definitely has its place but it’s generally a good idea to use positional parameters if you know they will be passed.

[spicybright]

It's impossible to see what arguments a function expects without reading all the code that uses it.

You can't always trust documentation to be accurate and up to date.