Operators can certainly be nice. And I do like allowing the programmer to create new ones too, though I'd tend to prefer the Haskell approach of creating new ones out of existing symbols like >< or such rather than the C++ approach of letting the programmer redefine an existing operator for a new use, << in the streams library being one of the worst common examples.
Python discourages using operators for things that don't have anything to do with their original use. If you try to be too clever with it, you run into issues. For instance, comparison operators are chained, so that `x > y > z` is equivalent to `x > y and y > z`, not `(x > y) > z`.
The most radical use of operators in the standard library that I know of is in pathlib, where `Path('/usr') / 'lib' == Path('/usr/lib')`, and I think that got a lot of pushback. It's certainly an outlier.
It fits well with Python's overall approach to readability. If the meaning of your operator isn't immediately apparent from its existing meanings, then it should probably just be a regular old named function or method instead. Python doesn't like DSLs very much.
Programmer-defined operators are certainly useful, but Python went in the other direction, which has its own advantages. C++'s choice to have a fixed set of operators but overload them in a lot of arbitrary ways is probably the worst of both worlds.
You should look at the Construct library, which overloads the '/' operator as syntactic sugar to make s-expressions in it's DSL less paren-heavy. I'm not saying I agree, but it was wild when I first saw it.
> Python discourages using operators for things that don't have anything to do with their original use.
Python doesn't really discourage anything and especially not overloading operators in weird ways. You even pointed out the pathlib insanity in the stdlib. Python isn't the shiny bastion of consistency and obviousness that the zen claimed it was years ago
Every C++ programmer knows that << is used for streaming, that is only a problem for purists or nitpickers.
So you really did pick the worst common example to illustrate you point... A good example is how "&" is used by boost serialisation to allow both serialisation and deserialisation of a value using the same expression:
obj & value;
Now that makes no sense at first sight. Still, not even this example can be used as an argument against operator overloading, because operators are just functions with predefined names and some expected behaviour.
The above could have been called as obj.serializeOrDeserialize(value) and it wouldn't have been much better. The problem is with the programmer that can't pick proper function names (where +, -, etc are also function names).
