Rendered at 18:00:56 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
reichstein 7 hours ago [-]
So the `+` is not _overloaded_, the `+` syntax is a shorthand for calling a method named `__add__` on the value of the first operand, with the value of the second operand as an argument . That is: `e1 + e2` is syntactic sugar for `e1.__add__(e2)`, no more and no less.
It's not "operator overloading" any more than two _different_ classes having a `length` property is "length overloading".
Using the term "operator overloading" to begin with is the error here.
AkBKukU 4 hours ago [-]
I think the bigger problem here is that "overloading" is specifically about providing multiple functions with the same name that take different parameters. You cannot truly overload in python, partly because it is weakly typed, and mostly because function names are a key in attribute dictionaries and must be unique.
The article is showing function overriding, not overloading, which is just standard class inheritance stuff.
benj111 5 hours ago [-]
If + silently gets translated to adding 2 numbers or joining 2 strings that is operator overloading, no matter how it's done under the hood.
If python had you write
e1.__add__(e2)
Or
S1.__join__(s2)
Then you would have 2 distinct operators, therefore no overloading.
Re classes.
Foo.len() and bar.len() are different. You can tell that when you are using them.
It's no different to
I_add() and f_add() they are both different functions.
If you automatically called one of those depending on whether the arguments were floats or ints, that would be overloading.
I suppose you could take it further and say that it's overloading if you have different int sizes.
But then we don't really class that as overloading, which I suppose demonstrates that it isn't a very precise term so there isn't much point getting particularly pedantic about it.
rf15 8 hours ago [-]
Good introduction to the space in Python (although a lot of languages have it, and just as many disallow it). I'm still on the fence regarding how useful or confusing it is. without (or even with) good variable names, "a + b" is an absolute mystery, especially when handling objects that come from classes you have no detailed internal understanding of.
sigmoid10 8 hours ago [-]
I feel like it is on you to understand these classes first though. In game engine programming, operator overloading is often just vector algebra. If you have no idea how matrix-vector multiplication works, then you have no business doing those things anyway, overloaded operator or not. But if you do understand it, it makes your code infinitely more readable than without overloading. And everyone with a math education will also understand that aspect of your code, no matter if they are familiar with your usual paradigms.
black_knight 6 hours ago [-]
Agda has the most wonderful (terrifying?) operator syntax I know of. Any Unicode (except for a few reserved words) can be used, and you can indicate where operandi go with an underscore. For instance defining a function named _•_ would allow you to use a • b.
But there is no limit to where the underscores go: the name _? Would give you x ? postfix. To define if-statements one defines the name if_then_else_.
faresahmed 3 hours ago [-]
Another comment already explains that this is regular method overriding in Python. Surely, some languages call user-defined operators 'Operator overloading' (e.g. C#) but the mechanism which Python uses (an `object` base class) IS overriding.
As to overloading as in multiple signatures (No types here!) for the same method name, it is not possible in the regular sense in Python since an object is more or less a dictionary of names. However, the dynamicity of the language will happily allow you to simulate it with YOUR own rules for disambiguation if you like. In practice, you'd 1. Don't 2. *args, **kwargs, Branches of is None and isinstance, etc.
It's not "operator overloading" any more than two _different_ classes having a `length` property is "length overloading".
Using the term "operator overloading" to begin with is the error here.
The article is showing function overriding, not overloading, which is just standard class inheritance stuff.
If python had you write e1.__add__(e2) Or S1.__join__(s2)
Then you would have 2 distinct operators, therefore no overloading.
Re classes.
Foo.len() and bar.len() are different. You can tell that when you are using them.
It's no different to I_add() and f_add() they are both different functions.
If you automatically called one of those depending on whether the arguments were floats or ints, that would be overloading.
I suppose you could take it further and say that it's overloading if you have different int sizes.
But then we don't really class that as overloading, which I suppose demonstrates that it isn't a very precise term so there isn't much point getting particularly pedantic about it.
But there is no limit to where the underscores go: the name _? Would give you x ? postfix. To define if-statements one defines the name if_then_else_.
As to overloading as in multiple signatures (No types here!) for the same method name, it is not possible in the regular sense in Python since an object is more or less a dictionary of names. However, the dynamicity of the language will happily allow you to simulate it with YOUR own rules for disambiguation if you like. In practice, you'd 1. Don't 2. *args, **kwargs, Branches of is None and isinstance, etc.
"self" aged well.