Defining new infix operators in Python | Hacker News Reader

Defining new infix operators in Python

code.activestate.com

23 pointsalrex02110 comments

I wrote a library to do this a while back: http://panchekha.no-ip.com:8082/programming/minioperators.ht...

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

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.

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.

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?

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.

Defining infix operators in Perl6 is very straightforward.

For eg:

    sub infix:<.oO>($name, $thought) {  
        say "$name thinks $thought"
    }

    "szabgab" .oO "Perl 6 is cool";

ref: http://news.ycombinator.com/item?id=1607254

Not everyone has the luxury of picking the language they work in. Organisational constraints etc.

It's useful to know how to achieve these things without throwing the baby out with the bathwater.

If someone has the luxury of choice they would probably opt for a real DSL, or a language such as Haskell that lets you define real operators.

Also, not everyone who uses Ruby likes crap like this. Just as not everyone who uses Python dislikes crap like this.

Reply on news.ycombinator.com