This is dangerous, asTransform.inverted returns acopy with a snapshot of the transform, and thus won't be in sync if the input transform changes. Instead, you'd probably want (identity - input).

I agree, but is it preferable to implicitly allow arguments to be mutated after the fact as a side effect at all? I.e., would a better way to ensure consistency be to simply copy the passed transform to begin with? Let me know which way to go (not sure if there's precedent here)

Yes, we tend to be lazily evaluated, e.g., if we hadAxes.transData here, it might change depending on limits (though of course that specific transform won't work here, being 2D, and as you've noted above this argument is 1D.)

Actually, I'm not finding that to be the case (that subtraction avoids inconsistency upon mutation), at least with theTranslation class I defined:

importmatplotlib.pyplotaspltimportmatplotlib.transformsasmtransformsclassTranslation(mtransforms.Transform):input_dims=1output_dims=1def__init__(self,dx):self.dx=dxdeftransform(self,values):returnvalues+self.dxdefinverted(self):returnTranslation(-self.dx)forward=Translation(1)backward=mtransforms.IdentityTransform()-forwardprint(forward.transform(1),backward.transform(1))forward.dx=2print(forward.transform(1),backward.transform(1))

prints

2 03 0

ReviewingTransform.__sub__, I can't actually say I understand how lazy inversion ever occurs... let me know what you think.

But your test is wrong? The second printout should be3 -1, ifbackward andforward are linked (which is what we want here, since the user only supplied the forward transform.)

That's my point -forward andIdentityTransform() - forward are not linked, and I don't see any mechanism for that operation being lazy inTransform.__sub__.

Oh, I see what you're saying now. Yes, I misremembered what happened there. What you will have to do is put alambda in that calculates the inverse when it's called.

Clever -2803407