[Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Yanghao Hua]

On Sun, May 26, 2019 at 6:05 AM Terry Reedy <tjreedy at udel.edu> 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 [1]  + [2] 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.

>   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.

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.