4 ms·
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(
by nmalaguti 5y ago
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 5y agoNot 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.
- IshKebab 5y agoThat's a good thing! Using `kwargs` is generally a terrible idea.
- DangitBobby 5y agoPlease elaborate.
- spicybright 5y agoIt'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.
- edgyquant 5y agoIn 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.
- SethMLarson 5y agoYep, 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!)