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.

I admit this (@=) is a much rarer case,

It is a different case.

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 [1] + [2] being implemented by the __add__ methods of int and list respectively.

 how does
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 x*y and X * Y are not confused.

--
Terry Jan Reedy

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to