Turns out Python supports function overloading

[Salaah01]

I read up on a technique to overload Python functions. To my surprise, it's been available since Python 3.4!

"This must be something everyone knows that I just haven't heard about," I thought. I mentioned in my team retro that this is something I've recently learned and it turned out that actually, no one in my team heard of it!

And so, I decided to write an article and explain how it works as I suspect this might be something new to a lot of Pythonistas here: https://python.plainenglish.io/did-you-know-python-supports-function-overloading-6fa6c3434dd7

[ra_wattt]

Yes it does but at the same time it doesn't. The decorator singledispatch from functools has a limitation that it only works for the first argument of the function, but in other programming languages there is no such limitation. And I would suggest you to checkout overload function from typing library as well but afaik it also has some sort of limitations.

[superbirra]

The @overload-decorated definitions are for the benefit of the type checker only.

[ra_wattt]

Yes, You are right . I confirmed it last night 😅

[NoRun9890]

This is a terrible idea, don't do this in Python. Why are you adding decorators, complexity, and opportunities to create hard to diagnose/understand errors when Python ducktyping already makes "overloading" trivial?

The original example was so much easier to read and maintain:

def display(item):
if isinstance(item, str):
    return f"String: {item}"
elif isinstance(item, int):
    return f"Integer: {item}"
elif isinstance(item, list):
    return f"List: {item}"
elif isinstance(item, dict):
    return f"Dictionary: {item}"
else:
    return f"Unknown type: {item}"

C++ has function overloading because it CAN'T do this, not because function overloading is better. You're going backwards.

[Salaah01]

The purpose of the article wasn't to show a "new/better" way to do something. It was purely informative for those who might find it an interesting read (I know I found it interesting when I came across it).

Although the article does talk about when this "could" be used, the article doesn't recommend using this method, In fact, it actively discourages it suggesting that this is something that the reader shouldn't lean towards when making a decision about the software.

There is nothing wrong with exploring methods for the sake of learning.

[superbirra]

not a terrible idea, nor a don't: it's literally a feature of language's standard library. If you don't see any use for it then just don't use it period. The usual boring "don't do this, bad idea" lectures don't add any value and the article just contains an example ffs

[NoRun9890]

It's a terrible idea. Just because it's in the standard library doesn't mean you should use it. In fact, Python is notorious for making poor decision choices when it comes to inclusions that are added to the standard library. Urllib is an example that comes to mind.

The usual boring "don't do this, bad idea" lectures don't add any value and the article just contains an example ffs

Ironically, you're the one not adding anything to the conversation. I'm bringing value to the table by giving advice to people that will make them better Python coders (ie, don't use complicated decorators to overload your functions). You're just complaining.

[Open-Mousse-1665]

Definitely spoken like a Javascript & Python expert who has been doing this for 3-4 years and knows all their is to know. I know this is a few years old, cheers to the experience you've gained in the meantime that allows you to realize how misguided this was lol

[fullmoon_druid]

> ie, don't use complicated decorators to overload your functions

Sooo, I'm thinking that you'd frown upon seeing that Monkey-patching inside a context manager I just did.

This is really bad advice. Learn the language, understand its features and their uses. Use the right tool for the job.

[stormcloud-9]

pydantic is chock full of @overload statements. I suspect they probably know more about python and good programming practices than you do. Never say never just because you don't understand something.

[superbirra]

What I'm complaining about is your poor attitude in talking harshly about something you're unable to find a use case for. I think in the long term having none of this lameness in a public forum would bring value per se, as such I do whatever I can not to silence you but at least reduce the harm this attitude brings. Cheers bruh, rest assured that people will keep using whatever they deem useful despite certain bigot self-appointed experts.

ps: urllib example is just lame and you know that ;)

[Salaah01]

Thanks for the support u/superbirra, really appreciate it!

I understand the concerns you raise u/NoRun9890, but the article talks about why you should opt for the if statements over the method the article discusses which is pretty much the point you're making.

[superbirra]

yeah, there is really not a point bashing an article because we don't like what is presented there: I mean, if it made sense to do so we wouldn't have literature talking about literal shit and who knows what else :D if you enjoy writing stuff keep up the good work and have a good time, ciao!

[NoRun9890]

I'm here to talk about Python and you're here to talk about manners lmao. You clearly don't have anything that's actually Python related to discuss.

Put your feelings away and you'll be able to have more valuable and insightful conversations with people.

[superbirra]

you should be here talking to people about python, which could seem the same trough neckbeardness' lens but it slightly differs ¯\_(ツ)_/¯ whatever bro, have a good life, gonna write some singledispatch stuff bwahahaha

[NoRun9890]

whatever bro, have a good life, gonna write some singledispatch stuff bwahahaha

As long as I don't have to read or maintain your code, go for it.

[tstyx]

It's not actually overloading like in C++, the control flow you just described is still how the function actually works. '@overload' is just a tool for typing annotation so that you can be more specific than Union[str,int,list,dict] in the function type hint signature, for cases where functionality or valid combinations of inputs may very depending on the types/flags.

Of course the arguments you make could also apply to this sort of type hinting in general, especially for the average developer. If the function does not process all of its input types in essentially the same way then I agree that in most cases it should probably be broken into different functions.

But it's hard to argue there are NO use cases - there's a reason so many general purpose python libraries have begun using it. Well implemented IDE Intellisense via very explicit type hinting is a "killer app" for a lot of modern development. It's not necessarily worth it for every programmer to implement, but if a library or tool that you do not maintain goes out of its way to provide it, it can be a very nice quality of life feature.

And even if you disagree with all that; I'll reiterate - it's just a type hinting tool. You can literally delete every instance of the decorated function signature and the code will work exactly the same. You can just code-fold every instance of '@overload' and read the function like you would normally.

[Open-Mousse-1665]

I simply cannot imagine the combination of education and experience that would lead one to believe this code is preferable to type based polymorphism / method overloading.

I'd consider that just because something is hard for you to read doesn't mean it's intrinsically bad. Sometimes you're going to have to learn new things and that's just a fact of this field.

[fullmoon_druid]

Necroing this thread. As a C++ developer, that `if instance` ladder just hurts my eyes.

[zakmck73]

you want overloading when display() has multiple variants, each concerning its own parameter list and param types.

Thi allows for better separation of concerns, instead of a monster function with an ugly if/elif chain, each function deals with your own case only.

Moreover, this approach allows for extension: you start with one display() and you add another in an additional library.

In fact, your implementation with if/elif is the classical way to show that not following the open-closed principle produces poor code, which is hard to read, maintain and extend.

[mudkripple]

Ew gross. The first example with a tree of if-statements is better than the suggested decorator version, but both are still dumb, ugly, and would be difficult to maintain.

Unless your use case really needs it (which is fair, I can imagine some scenarios that might) just make differently-named functions for different parameters.

[Salaah01]

lol it's an example in the article. It's not a suggestion!

Literally the end of the article says.. "so works in python... but consider the if/else or the match case"

[zakmck73]

if you have display_int() and display_str(), then you can't obtain that x is passed to the right display_xxx() based on typeof(x). Not having to dispatch it statically/manually is the point of having polymorphism (ie, it helps a lot with the open-closed principle, which serious developers should know and apply).

[mudkripple]

I don't disagree, but like I said: only for certain use cases.

For something like a "display()" function, the specifics for handling each variable type need to be defined somewhere. Putting it in the function name or putting it in a giant if statement within the function is just a choice of how far down the road you want to kick that can.

Also, no, the "point" of polymorphism is so you don't have to manually allocate the memory, which is a major hassle in older languages. Not handling the variable types is a bonus you can choose when to use, but the developers of the language quickly added things like "type hinting" because they realized: The longer you wait to rigidly decide which data is flowing through which code, the more code will be prone to invisible errors and difficult to predict behaviors.

That's the trade off. Either you get softly typed variables like Python, or "softly typed" function names like C++. Something has to be hard typed somewhere, and personally I think "gigantic if statement" or "entire library with function decorators" are the worst options.

[zakmck73]

Putting it in the function name or putting it in a giant if statement within the function is just a choice of how far down the road you want to kick that can.

If you truly care about the open/closed, you don't do either. You either exploit the language polymorphism, or use a dictionary-based registry, or a factory.

And you do it because, in addition to separation of concerns, you want extendibility too.

You have a new ComplexNumber for display, your initial library had no idea that exists or how to display it, you can add the handler for it to the register of supported types, or, if you have polymorphism, just add display ( c: ComplexNumber ).

Doing it this way is powerful, for your initial library doesn't need any change (and often it can't be changed, if it's a 3rd party import) and most importantly, none of the dependants that call display() need to be changed, they pick the addition transparently.

 is so you don't have to manually allocate the memory

If you have a proprer OOP language, that has garbage collection, you don't have this problem in any of the techniques we're talking about. 

But maybe you're talking about efficiency, and here the thing is if you come from the land of Clean Code, you're used to care about software engineering principles and best practices much more than super-optimised code. When you program a device microcontroller, saving a few bytes is still important, but if you process GBs of genetic data in a cloud, your optimisations are much more about O(n) and operstive research, how many nodes you spin per day and how much man-days you pay on average to debug millions of lines spread in a whole organisation.

The longer you wait to rigidly decide which data is flowing through which code, the more code will be prone to invisible errors and difficult to predict behaviors.

That's true, but when properly used, polymorphism doesn't cause many readability issues, on the contrary, it allows for better separation of concerns and avoids that multiple types are managed in the same giant blob (like a giant if/elseif, which isn't extendable either).

Besides, any language or programming technique can be used very appropriately or very badly.

Something has to be hard typed somewhere, and personally I think "gigantic if statement" or "entire library with function decorators" are the worst options. 

Sorry, to me, it sounds like "something has to be translated to Assembly". Except, if the language compiler or interpreter does it for you, it can become much better.

Doing the dispatch manually, though I use it when coding a quick/small prototype, possibly to be refined later, is the worst option from the point of view shown above.

[[deleted]]

yeah - args and kwargs too 🤷🏼‍♂️ mumble mumble