4 ms·

On one hand - I agree, overloading isn't great. On the other hand having a `def func(args, kwargs)` is a pain the ass for everyone involved (people & IDEs): you

On one hand - I agree, overloading isn't great. On the other hand having a `def func(args, kwargs)` is a pain the ass for everyone involved (people & IDEs): you have no idea what the args or kwargs could be without reading the source. If you can get away with just a bunch of named kwargs after the arguments that is fine, but I'd take overloading over the `args, kwargs` garbage any day, even if that is the more "pythonic" way.

rusk 7y ago
I think the kwargs approach is fine for when you’re reading your code. When you’re writing I think you’ll always have to consult the docs, or headers. In a strongly typed language IDE can pick up the hint but in a more dynamic language like python it can get confused.
- testuser66 7y ago
  My bad - I meant this but didn't know how to format code so that is showed the stars def func(*args, **kwargs) I am in full support of actual kwargs with names, it's the wildcard ones that I don't like.
joshuamorton 7y ago
by "kwargs" the usual approach is to have optional arguments ("keyword arguments") that aren't just kwargs, but are named optional arguments: def func(args, flag=False, flag2=True)
- 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 ago
      And 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]):

rusk 7y ago

I think the kwargs approach is fine for when you’re reading your code. When you’re writing I think you’ll always have to consult the docs, or headers. In a strongly typed language IDE can pick up the hint but in a more dynamic language like python it can get confused.

testuser66 7y ago
My bad - I meant this but didn't know how to format code so that is showed the stars def func(*args, **kwargs) I am in full support of actual kwargs with names, it's the wildcard ones that I don't like.

joshuamorton 7y ago

by "kwargs" the usual approach is to have optional arguments ("keyword arguments") that aren't just kwargs, but are named optional arguments: def func(args, flag=False, flag2=True)

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 ago
    And 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]):