The ability of **kwargs to leave behind no proper documentation and silently swallow any invalid arguments has made us remove them entirely from our codebase. They're almost entirely redundant when you have dataclasses.
Python Type Hints – *args and **kwargs (2021)
11–20 of 158 posts
Re: Python Type Hints – *args and **kwargs (2021)
#12Why do people not just type everything they want passed? def variable(n:str, nn:str, nnn:str, *, a:int, b:int, c:int) Anything after,*, is a kwarg.
Your signature requires exactly 3 positional[0] and 3 keyword arguments. The OP allows any number of either. [0] actually 3 positional-or-keyword which is even more widely divergent
But why would you want that doesn't that make for a more confusing api? Would it not be better to just have everything as a kwarg? You would get better types that way
Re: Python Type Hints – *args and **kwargs (2021)
#13The ability of **kwargs to leave behind no proper documentation and silently swallow any invalid arguments has made us remove them entirely from our codebase. They're almost entirely redundant when you have dataclasses.
Yea, really only useful imho for proxy functions that then just pass the arguments along to something that DOES properly type every arg.
Re: Python Type Hints – *args and **kwargs (2021)
#14This does restrict all of your keyword arguments to the same type. If you have keyword arguments of different types, you're right back to no type safety.
Well, if you want to type your kwargs and use newer versions of python, you can use Unpack with typed dicts to achieve that. But the footgun there is that you can't redefine fields when extending them, so no Partial for you.
Re: Python Type Hints – *args and **kwargs (2021)
#15Why do people not just type everything they want passed? def variable(n:str, nn:str, nnn:str, *, a:int, b:int, c:int) Anything after,*, is a kwarg.
It's pretty common when wrapping a function that has a large number of config options.
The wrapper is usually some shorthand for building a handful of those args or adding some side-effect, while still allowing the caller access to the remaining config options via kwargs.
Here's one example of that in the wild https://matplotlib.org/stable/api/_as_gen/matplotlib.pyplot....
Re: Python Type Hints – *args and **kwargs (2021)
#16Although these two comes in handly, people have been using them wrong. Often in scientific open source package, they slap *kwargs in function definition without documentation. How am I suppose to know what to pass in? https://qiskit.org/ecosystem/aer/stubs/qiskit_aer.primitives...
Sadly a problem with any wrapper function is that it nullifies this kind of information. Use functools.wraps.
Re: Python Type Hints – *args and **kwargs (2021)
#17The ability of **kwargs to leave behind no proper documentation and silently swallow any invalid arguments has made us remove them entirely from our codebase. They're almost entirely redundant when you have dataclasses.
I agree - it is convenient to use at first but it sure makes it hard to use an unfamiliar codebase!
Re: Python Type Hints – *args and **kwargs (2021)
#18now try typing a decorator
https://stackoverflow.com/questions/47060133/python-3-type-h...
what a disaster
Re: Python Type Hints – *args and **kwargs (2021)
#19Although these two comes in handly, people have been using them wrong. Often in scientific open source package, they slap *kwargs in function definition without documentation. How am I suppose to know what to pass in? https://qiskit.org/ecosystem/aer/stubs/qiskit_aer.primitives...
Sadly a problem with any wrapper function is that it nullifies this kind of information. Use functools.wraps.
My question is that can @warps warp more than 1 function?
Maybe in some use case people need to merge 2 functions into 1, I don't know if it can handle this situation.
Re: Python Type Hints – *args and **kwargs (2021)
#20Although these two comes in handly, people have been using them wrong. Often in scientific open source package, they slap *kwargs in function definition without documentation. How am I suppose to know what to pass in? https://qiskit.org/ecosystem/aer/stubs/qiskit_aer.primitives...
Especially when they don't even leave a doc string so you're forced to track down the packages documentation online just to interact with certain interfaces.
I work in a large python codebase, we have almost no usage of `*kwargs` beyond proxy methods because of the nature of how they obfuscate the real interface for other developers.