[PEP draft 2] Adding new math operators

[Huaiyu Zhu]

I agree with most of Greg's reply.  Here are a few more.

On 09 Aug 2000 09:43:39 +0200, Konrad Hinsen <hinsen at cnrs-orleans.fr> wrote:
>>    Disadvantage:
>>    - Hard to maintain in current Python because ordinary numbers cannot have
>>      class methods.  (a.E*b will fail if a is a pure number.)
>
>That's trivial to change, numbers can in principle have attributes
>(and thus methods) just like any other type. For syntactical reasons
>one would have to write parentheses around number constants, e.g.
>(2).E, but that should be hardly needed in practice.

I did not say it clearly.  Numbers can have builtin methods, but can't have
user defined methods.  So (2).E would work if .E is hard coded in python,
but not if you try to define it yourself.  It's not the parser issue.

>
>>    - Difficult to implement, as this will interfere with existing method
>>      calls, like .T for transpose, etc.
>
>What kind of interference? There is certainly no shortage of attribute names!

Those listed by Greg are quite representative.

>
>>    - Runtime overhead of method lookup.
>
>Negligible for types implemented in C, but significant for Python classes.
>Question: how often would this lookup happen in practice?

Agreed.  I forgot to mention object initialization, which include a lot of
conditional for determining operand type.

>>    - The shadowing class cannot replace a true class, because it does not
>>      return its own type.  So there need to be a M class with shadow E class,
>>      and an E class with shadow M class.
>
>I don't quite understand this. In practice, the two classes would be
>an "array" and a "matrix" class. Both would be standard classes with
>constructors etc., there is no need for a special "shadow" class with
>different behaviour. Array objects would have an attribute called
>"matrix" whose value is the equivalent matrix object, and vice versa.

Exactly as Greg summarized.  There were two kinds of proposals in previous
discuss (suppose a, b are matrices)

(1) a.E*b     -> return matrix
(2) a.E*b.E   -> return array

Method (1) is what's in the PEP.  In this case, a.E is an array class that
is only a shadow of matrix class.  Likewise, if a is array, a.M would be a
shadow matrix class.  Their whole purpose would be an indicator for the
following operand.

Method (2) appears to be what you and Robin have in mind.  The problem is,
as discussed before, you have to remember the identities of a and b to
understand what a+b means.  I did not include this in the PEP because
someone said "Nobody ever considered your second interpretation" and no one
objected so I though I must have had dreamed this up. 

>I think this approach deserves a much more serious study, because it
>is much more "Python-like", and requires no syntactical changes.
>Lobbying for attributes on number types will be a lot easier than
>lobbying for new operators.

Issues for adding number attributes:
1. Do we need both elementwise and objectwise?
2. Do we need to assign semantics to MatPy and NumPy in the language?
3. Would (2).E==2?  Would (2).E is 2?  
I know people could answer these with various yes and no, but the real
challenge is to answer them with a wel though of design.

I would have no problem with this if it were implemented.  If someone could
present a coherent design that addresses all these problems, it would be a
realistic option.  At the moment any implementation I could think of are
messy and unpythonic in many ways.  Waiting for type-class unification is
not a realistic option for the issue at hand, either.

Here's a chanllenge: Could someone help to rewrite this alternative so that
it could appear as an equal contender with the main proposal?

Huaiyu