Clever hack. But this is one of the key differences between Python and Ruby. In Python, you're not supposed to hack the language like this. The benefit is that Python code remains readable without having to understand how the language has been "altered" in each specific project.
If you want to do this level of hacking with the language, why not just use Ruby?
I am always amazed how people consider defining new infix operators to be on a whole new level compared to defining `ordinary' functions.
Go, check out Ocaml or Haskell, even some Lisp. Operators are functions. And there's nothing mythical around it.
It's only that most parsers weren't able to handle user-defined operators for a long time that makes the idea seem so foreign. (And C++'s `clever' idea to re-define operators already in use did not help the situation, either.)
> people consider defining new infix operators to be on a whole new level compared to defining `ordinary' functions
It has nothing to do with the concept of defining new infix operators. It is to do with hacking the language in a way that is unexpected and (initially) confusing.
Hacks like this are clever and interesting, but not Pythonic. Doing this over using an "ordinary" function just makes Python harder to read because it is not conventional and not idiomatic. Any programmer competent in the language should be able to dive in without having to understand which set of hacks have been used. It doesn't matter whether it is mythical or not; it should not be used because it is a hack.
Actually, I think defining new operators is impossible to do even this cleanly in Ruby. It's emphatically not well suited to this particular kind of metaprogramming. You can override lots of operators and define methods that read kind of like language keywords, but AFAIK you can't define new infix operators without flat-out hacking the parser in C.