Oh, forgot the main reason why I started being bothered by this.

A lot of places in the code use "+=" to combine transforms, such as in _make_image, where we do

            t += Affine2D().scale(1.0 + extra_width, 1.0 + extra_height)

In this case (and often, in general), whether this gets added on the right or left matters. So having it be feel ambiguous with "+=" makes life harder for someone trying to read/understand this code.

At least, I know I personally have to drop a break point (or lookup how __add__ interacts with "+=" in the Python docs) anytime I see this kind of thing.

This was just discussed in #17206 (comment) / #17217 / #17218. I personally think +/- actually work better here (well, in particular there's no - for @ (aka no left-divide) and that's a real problem).

Oh sorry, github didn't recommed those to me, I'll close this.

Seems like the main con is actually losing the ability to cleverly make

A @ A.inverted() == IdentityTransform()

return True.

So in order to get feature parity, we'd need .inverted to return an InvertedTransform of some sort so that CompositeGenericTransform can check if things cancels exactly when evaluating "@".

Seems like an additional complaint is also that B**-1 @ A and (1/B) @ A aren't as "pretty" as "A - B". I disagree, since we don't typically have long chains of transforms to make it unwieldy to just type B.inverted() @ A. And if we do, I think that's honestly more readable than B - A. The latter is now well documented (thanks @anntzer!) but to be fair, the former doesn't even need documentation. It just works the way you think it does.

To me, it seems like having code that makes A.inverted() @ A evaluate to exactly IdentityTransform is no better or worse than having special code to check that A - A does (i.e. hiding that behavior in a separate operator seems unnecessary except for ease of implementation ).

I'll reopen this if people are favorable to something like this (i.e. .inverted to return an InvertedTransform of some sort so that CompositeGenericTransform can check if things cancels exactly when evaluating "@") happening, but seems like on top of this now being tricky to implement there's considerable push back on changing it at all.

Having a real InvertedTransform() was proposed at least once (by @ImportanceOfBeingErnest iirc? you'll have to look it up) to get a non-frozen inverse() (i.e. one that keeps track of changes in the original thing); I think it would be usefule, and I guess it would be a prerequisite for a switch to matmul to happen (even though right now I still don't like it).

Looks like it was proposed in #10741.