3 ms·
I fully agree that named kwargs is perfectly acceptable, but this is the version I think is horrible: def func(*args, **kwargs) is valid and completely a
by testuser66 7y ago
I fully agree that named kwargs is perfectly acceptable, but this is the version I think is horrible:
def func(*args, **kwargs)
is valid and completely ambiguous - you have no idea what it's doing unless you read the source, and track down how it branches out. IDEs are stopped dead in their tracks as they aren't going to parse the logic to figure it out
And yes it's not the most common approach, but I have seen it enough times to despise it. This overloading approach removes the need for it so I'm all for that.
- joshuamorton 7y ago> This overloading approach removes the need for it so I'm all for that. Ish, see if your IDE supports it (hint: it won't, but it will support named kwargs).
- testuser66 7y agoAnd it doesn't really need to. Consider this: from functools import singledispatch from typing import Union @singledispatch def myfunc(arg:Union[int, str]): print("Called with something else") @myfunc.register def _(arg:int): print("Called the one with int") @myfunc.register def _(arg:str): print("Called the one with str") myfunc(123) myfunc("123") Everything works as you'd expect, and the IDE's type hints are accurate as long as you actually put the correct type hint def myfunc(arg:Union[int, str]):