[Python-Dev] Infix operators
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.,
> 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:
> 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
> 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
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 '$'
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