[Python-Dev] Infix operators (original) (raw)

Josiah Carlson josiah.carlson at gmail.com
Thu Jul 24 01:11:19 CEST 2008

On Wed, Jul 23, 2008 at 2:14 PM, Sebastien Loisel <loisel at temple.edu> wrote:

Dear Pythonistas,

I've googled for this but I wasn't able to find anything definitive. I was recently looking at scipy to see if I could use it in stead of MATLAB for my class on numerical PDEs, but I noticed that there's some difficulty related to the notation; mainly, the matrix multiplication, and the linear solver (i.e., MATLAB's \ operator). After giving it some thought, I've decided to hold back for now and use MATLAB. Since scipy/numeric python have been around for a while and some of it is even integrated in Python 2.5, I'm sure this conversation has happened before, so please just educate me. Now I think that there's always going to be people wanting more and more operators in Python (although the operators I'm talking about are privileged -- the Chinese were using matrices some 2000 years ago), so I was thinking that it would be simpler to have a way for defining new infix operators, which would simply be binary functions whose names are punctuation marks; see any language with this feature, e.g., Haskell. Now since this is such a simple idea, I'm guessing it occured to pythonistas at some point in 1992, and got voted down and that decision has now become scripture. Is that the case? The one thing which I found was PEP 211 http://www.python.org/dev/peps/pep-0211/, which has an amazing quote from James Rawlings. His comment about inv is completely absurd, and while he claims not to know \ and /, he is quoted as an authority on these operators. This particular PEP should probably be deleted from history. For a more authoritative explanation, a quick search yields MathWorks' own Loren Shure: http://blogs.mathworks.com/loren/2007/05/16/purpose-of-inv/ Essentially, in almost all applications, inv(A) is entirely wrong. You can ask any numerical analyst who works with large problems, and they will confirm it. One of the main reason is that, even if A is sparse, inv(A) is full. That absurdity aside, if I were a language designer, I would be reticent to add one operator to Python (like in PEP 211), because there will always be more operators that people want (how long until someone asks for an operator for the Kronecker product or the convolution?) But why not put in this infix possibility?

Why not add the possibility for arbitrary infix operators? Others will most likely disagree with me, but I would claim that adding arbitrary infix operators are a great way to destroy readability. What the heck does 'x = 4 $ 6' mean in Python? Oh, that's right, it's a custom infix operator. But where is it defined? In the module? In some other module that is imported? Can I override or do some pre-processing to the arguments and pass it on to the previously defined $ operator? So many questions, none of which tell me what '$' does.

Really though, PEP 211 was a perfect example of a k-line function that someone attempted to make syntax that really didn't need to be syntax. And arguably, any infix operator will need to result in a lookup for the new infix operator, which will be as fast (or slow) as a globals lookup, so you may as well define your operator as a two-argument function, which has defined semantics, and can be imported and passed just like all functions defined for years.

I would argue current operators are convenience for the 99%+ majority of "mathematical" operations done in Python, with well-defined and understood semantics in the 99%+ cases they are used for. Further, the addition of further infix operators are, strictly speaking, a domain-specific language, which Python (as a language) doesn't frown upon, but doesn't encourage either.

If you still think that X \ Y would honestly make Python a better language, I would ask you if logix (http://www.livelogix.net/logix/intro.html) would suit you better. It seems to allow you to use arbitrary punctuation for operators.

More information about the Python-Dev mailing list