On Sun, May 26, 2019 at 6:05 AM Terry Reedy firstname.lastname@example.org wrote: >
On 5/25/2019 3:09 PM, Yanghao Hua wrote:
@= has all the same issues like <<= or >>=,
No, it does not
in that you are basically sacrificing a well known number operation
because @= is not a number operation at all.
Yes you are right. @ is not a number operation, it is number-collection operation. What is preventing the same operation on signal-collections?
I admit this (@=) is a much rarer case,
It is a different case.
Really not much different for me as you can use it to operate on matrix (which can be either a matrix of number or matrix of signals).
but why do we want to exclude the possibility for a matrix of signals to multiply another matrix of signals and assign the result to another matrix of signals?
We do not. <int subclass instance> @= int would be implemented by the __imatmul__ method of the int subclass. matrix @= matrix is implemented by the __imatmul__ method of the matrix class. This is similar to 1 + 2 and  +  being implemented by the __add__ methods of int and list respectively.
I really don't understand the argument here. And let's apply the same argument to PEP465 why not matrix multiply override <<= instead? For me not using @= is exactly the same reason for not using <<= and others.
this look like? X @= (X @ Y), where @= means signal assignment, and X @= Y, does it mean signal assignment of Y to X, or does it mean X = X @ Y? This simply causes a lot of confusions.
Why don't people more often get confused by a + b? Partly because they use longer-that-one-char names that suggest the class. Partly because they know what a function is doing, perhaps from a name like set_signals. Party because they read the definitions of names. Conventionally in math, scalars values are lower case and matrices are upper case. So xy and X Y are not confused.
I think people don't get confused by a + b because a + b does mean a + b and does not mean a * b and it has nothing to do with how you name the operands.