

Defining new infix operators in Python - alrex021
http://code.activestate.com/recipes/384122/

======
pavpanchekha
I wrote a library to do this a while back: [http://panchekha.no-
ip.com:8082/programming/minioperators.ht...](http://panchekha.no-
ip.com:8082/programming/minioperators.html)

Hope someone finds it useful, though to be honest, I don't think this sort of
thing is very commonly useful.

------
viraptor
Unfortunately this is not a "proper operator". For example, both sides need to
be evaluated, so it cannot control the program flow.

Still, I really like the _inrex_ module in the last comment. Great extension
to the very clumsy _re_.

------
rlpb
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?

~~~
eru
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.)

~~~
rlpb
> 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_.

~~~
eru
Yes, you should probably stay away from too clever hacks in production code.
But pushing the language for fun is fine with me.

Perhaps somebody will even write up a PEP for properly defining your own
operators?

