Discussion: new operators for numerical computation

[Huaiyu Zhu]

Would someone like to make a brief summary of the thread on (*) type
operators?  I did not follow all of them, and can't seem to be able to
figure out what the consensus is now.  Whether this goes into the PEP, it
would be nice to have a summary of the discussion so far.  Thanks.

John, would you volunteer?

Huaiyu

On 21 Jul 2000 07:24:31 -0500, John Lull <lull at acm.org> wrote:
>"Rainer Deyke" <root at rainerdeyke.com> wrote (with possible deletions):
>
>> "John Lull" <lull at acm.org> wrote in message
>> news:ueefns037mjarv63dqpbh52mmr1k6vvaop at 4ax.com...
>> > This shouldn't be hard to parse.  In fact, it might be a reasonable
>> > foundation for class-specific operators:
>> >     A(.opName)B
>> > would get executed as either
>> >     A.__opName__(B)
>> > or
>> >     B.__ropName__(A)
>> > or raise an exception as appropriate.
>> 
>> This would allow constructs such as:
>> 
>> A(.init)B
>> 
>> In other words, it would turn all existing __magic__ functions into
>> operators.  Not a good idea IMO.
>
>
>One could easily prevent that by having
>    A(.opName)B
>invoke
>    A.___opName__(B)
>instead of
>    A.__opName__(B)
>or some such.
>
>Clearly there's nothing to force use of the same naming convention for
>these operator methods.
>
>Regards,
>John

-- 
Huaiyu Zhu                       hzhu at users.sourceforge.net
Matrix for Python Project        http://MatPy.sourceforge.net