[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