[PEP draft 2] Adding new math operators

Huaiyu Zhu hzhu at localhost.localdomain
Wed Aug 9 14:27:51 EDT 2000


On Wed, 09 Aug 2000 11:28:29 +0200, Gregory Lielens <gregory.lielens at fft.be>
wrote: 
>
>A -> matrix
>B -> matrix
>A.E -> array
>A.E*B -> matrix 
>A.E*B.E -> matrix
>sin(A.E) ->matrix
>A.E.T  -> maybe matrix, or probably error (what is the elementwise
>transpose? no idea!) 
>A.T.E  -> array
>A = B.E -> A should be a matrix (is it possible? I do not think so...)
>and so on...(in NumPy, where array is the default, reverse the
>behavior...)
>
>This "non-persistent" (better than shadow?) behavior is preferable,
>because one want to avoid backtracking the code to know the type of a
>variable to know the meaning of an operation (At least, I would prefer
>to avoid that :-))...
>Such non-persitent behavior plead for operator distinction instead of
>type distinction, imho, and the last example is the one which makes me
>feel really uncomfortable about .E
>
>Well, Huaiyu, if this is not what you mean by shadow class, please
>correct me!
  
Better than I could put it.  Thanks a lot!


>> 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.
>
>Yep, I agree...I hope this message qualify as a part of this study!

The more I think about this approach, the more uncertainties it presents. It
is the task of the proponents to present a design so that all these would be
fixed in a coherent way.  My impression is it requires much larger changes
to current Python than adding operators.

Huaiyu



More information about the Python-list mailing list