[appplication]

Either copy/paste or rolling them into config objects and passing those down is generally preferable. Copy paste doesn’t always feel great for pass through arguments but it’s perfectly interpretable.

Naked kwargs is so difficult to work with that I hesitate to think of a use case where it wouldn’t be an anti pattern.

[memco]

> Either copy/paste or rolling them into config objects and passing those down is generally preferable

Preferable for whom? I do not prefer it. I much prefer to avoid the extra work it creates for me vs. the simplicity of kwargs. I use explicit args for the function I made and then add *kwargs on the end and then I don't have to write bespoke config objects or copy and paste a bunch of stuff that might be obsolete by a future update to some library and also pollute my function's signature. I would very much welcome a way to tell callers where kwargs is going without having to do extra work.

[appplication]

Preferable for those who would use your code. If it’s just you then it’s your exclusive preference. If you have users, args/kwargs is going to be more opaque than a more explicit option.

For code with many users, creating a few extra minutes of work for one dev is preferable when the alternative would be every dev who uses that code has to spend that same extra work and then some to grok what exactly is going on with the method signatures. Being explicit also creates traceable code, in that you can search a keyword to find everywhere it’s used or passed rather than tracing methods where it might be used.

I can promise very few users would be thankful for the elegance and minimalism of args/kwargs when they’re source-diving trying to figure out how to get some basic functionality to work.

[paiute]

I think people kind of miss the idea of kwargs in python, the idea is that they are a dict. You can cast a dict to kwargs, in contrast to positional args. I see the typedict being super useful. I really don’t see your argument and would say that this typed dict is more developer friendly than having positional arguments. https://docs.python.org/3/tutorial/controlflow.html#more-on-...

[memco]

I haven't often been the designer of code others have used, but I have used someone else's wrappers for libraries that we use in many parts of our code. My experience of trying to use their wrappers has been a guessing game of how they decided to arbitrarily rename an argument and finding places where they don't support arguments that I need. I get that kwargs is a bag of mystery and that there is benefit to being explicit, but it comes with tradeoffs. I don't like really like kwargs, but sometimes the use of kwargs better serves the purpose than the alternatives. I've looked for solutions, but haven't found anything that avoids the above issues. If anyone has tools or techniques that eliminate these pain points please share. The typedDict is promising, but I'm not sure how composable they are. Time will tell.

[dbrueck]

I think naked kwargs can be abused, but there are many legitimate use cases for them. For example, we interface with a message bus that uses JSON for transport. There are several different ways to enqueue a message onto the bus, and it would add a ton of complexity and no real value to define the parameters for each of those Send APIs.

Looking at it another way, the hunk of code in charge of serializing your message does not care one whit about the innards of each message, and making it become aware would add tremendous complexity with no real value.

[rpcope1]

There's at least a handful of places that you can't escape them, one of the most evident in my mind is when constructing higher order functions or other decorators. Maybe a simple example would be a retry higher order function (or decorator), where you can't know the arguments and their form ahead of time, and want to invoke the wrapped function as is (and only do something like repeating if an exception is triggered). Keyword arguments are helpful for writing certain kinds of generic code, but definitely can be easily abused (much like most of the meta-programming facilities in Python).