Matlab vs Python (was RE: Discussion: Introducing new operators for matrix computation)

[Huaiyu Zhu]

I really like this kind of ideas.  Anyone able to implement it?  What it
takes to change a patch of grammar to an importable module?

Maybe the way to do it is to change the python implementation of operator
into an object oriented approach?  Similar to PyObject we'll have a
PyOperator which defines the symbol, name, scoping and precedence rules.
This way handling operators within python would be similar to hadling
ordinary objects, by import NewOperator.  To discourage abuses there may be
restrictions on what is allowed as symbols and what precedence rules are
allowed and so forth, and perhaps prohibit dynamic changes within an
importing module.

If everything about operators is concentrated within one class I think this
will also make python itself simpler.  In any case I think this fits in the
idea of doing things in organized way and removing arbitrary restrictions.

(This is just my guesstimate so that others may come with hard facts.)  

Huaiyu

On 18 Jul 2000 09:51:52 -0500, John Lull <lull at acm.org> wrote:

>How about one small change to Python, breaking no existing code, and
>applicable (I'm sure) to domains far-afield from linear algebra:
>
>Currently,
>    object operator other
>is really just convenient shorthand for:
>    object.__operatorname__(other)
>or
>    other.__roperatorname__(object)
>where operator is any binary arithmetic operator.
>
>What if we simply make
>    object @operator other
>convenient shorthand for:
>    object.__alt__operatorname__(other)
>or
>    other.__alt__roperatorname__(object)
>for all those same operators?
>
>This would be a syntax error when applied to anything other than an
>object, and would raise an appropriate exception if neither object nor
>other provided an appropriat __alt method.
>
>This would provide a way of adding a reasonable variety of
>domain-specific operators to *any* class with very little impact on
>the language, zero runtime penalty, and obvious & correct behaviour
>when creating derived classes.  It would not break any existing code
>and should be very simple to implement.
>
>I haven't thought through whether the same behavior should apply to
>anything other than binary arithmetic operators.  Doing so would seem
>very Pythonic.
>
>Regards,
>John