On Wed, Jul 23, 2008 at 2:14 PM, Sebastien Loisel <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
