Bug report

Bug summary

While working on fixing the transform pipeline for image rendering, it struck me that the operator "+" probably sends the wrong impression to users in terms of expected properties. The Euclidean group is barely associative, and definitely not commutative.

Also, since aTransform is something that'sapplied (like an operator), my expectation as I'm using composite transforms is that they will be applied rightmost-first. In other words, I keep expecting

>>> (A+B).transform(X)==A.transform(B.transform(X))# but it's currently False>>> (A+B).transform(X)==B.transform(A.transform(X))# how it currently works.

Now that Python has the "@" operator, this feels like a more natural choice for "combining"Transforms. People don't generally expectA@B == B@A, while they do expectA + B == B + A, which is definitely not true for Transforms.

The implementation would just be something like (modulo deprecation code)

def__matmul__(self,other):returnother+self

And we would get

>>> (A @B).transform(X)==A.transform(B.transform(X))# returns True

Release strategy

Fixing all our internal uses is (probably) only one PR's worth of work, since (relative to how much code would churn) it would be easy to verify/review.

However, to me this feels like an integral enough part of the Transform API that it might make sense to leave in "+" until 4.x, and maybe just make sure we only advertise "@" in e.g. the tutorials?

In summary:

Pros

1. "@" implies lack of commutivity, whereas "+" implied commutivity
2. "@" implies order of application (rightmost-first), whereas "+" is ambigious

Cons

1. Pretty core part ofTransform API
2. Lots of code-churn inTransform-related internals.