[Python-Dev] Infix operators

[Josiah Carlson]

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.

 - Josiah