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/
