I don't think we need "scale" in here. It's just the copy feature that we provide and doesn't have to say anything on who may use it.

While historically, we did not call mixins*Mixin, I think it's good style to do so, and there is precedence with_BlendedMixin.

sure, plus or minus spelling ;-)

Sorry to nitpick about this, but I think it makes a lot more sense to instead have

classIdentityTransform(CopyableTransformMixin,Transform)

intransform.py. Then you can just returnIdentityTransform below and not have to create theLinearTransform class at all. That was my take away from the call today, but@timhoffm approved already so I may be missing something?

What is the difference between this and doing it in scale.py where it is needed? We really don't particularly want people using a special version oftransform.Identity do we?

Ah, I emphasized the wrong thing. the point is tonot make a special Transform class at all, but instead to add copy and deepcopy ability to therealIdentityTransform (using the mix-in). Then you don't need the extra class at all, I think.

Sure I understand. But my point is that all the other scales have a named transform associated with them, I think its fine for the linear scale to have a (trivial)LinearTransform that is associated with it. The advantage is that the goofy mixin is confined toscale.py, and we don't pollutetransform.py.

The discussion aboutIdentityTransform on the call was pointing out that it definitely didn't need to have a stricture against copying, but to my mind that just goes to@anntzer 's overall point that copying all the transforms could be reconsidered. But that is a 3.5 sort of thing, not a release-critical 3.4 fix.

I agree with@brunobeltran (@brunobeltran thanks for catching this. I was too concerned with naming the mixin 😄).

We have scales and transforms that are associated with it. For nonlinear scales we need special transforms and it's natural that a LogScale is connected to a LogTransform. However, for a linear scale we don't need a transform (or only the identity). Making aLinearTransform, which is effectively anIdentityTransform only for the sake of matching the name is more confusing than helpful (that's also what got me confused in the first place in yesterdays discussion).

Note also the docstring ofLinearScale.get_transform():

   Return the transform for linear scaling, which is just the   `~matplotlib.transforms.IdentityTransform`.

Given that te mixin is private again, we're not polluting the namespace oftransform.py if we put it there.

Sure but it is strange to have a mixin that we use once in the transform module and a bunch of times in the scale module. Particularly when the mixin is really only needed for the scales to work. I think it just makes things unnecessarily complicated.

I think which is more complicated is in the eye of the beholder. I personally find the purpose of the mix-in to be clear from the name. On the other hand, an equivalent solution (that it sounds like you like better) would be to just have:

(in transforms.py):

class_CopyableTransformMixin():    ...classIdentityTransform(Affine2DBase,_CopyableTransformMixin):    ...class_CopyableTransform(Transform,_CopyableTransformMixin):pass

then inscale.py, we simply do

frommatplotlib.transformsimport ...,_CopyableTransformclassFuncTransform(_CopyableTransform):    ...

Then there's not a mixin scattered over two files, the semantics of what's going on are confined to justtransforms.py, and what we get is thatIdentityTrasnform now copies correctly, and no users are confused about what this "LinearTransform" object is that quacks like IdentityTransform but has a different name.

(Bonus) whoever ends up making all Transforms copy-able in the future has a nice framework to start working within.

I like the current solution better where nothing changes intransform.py and all the changes are inscale.py.

I don't think this is the correct framework for any fundamental changes toTransform that allow it to be copyable in general. That will require substantial more state checking etc that are beyond a simple mixin.

I'd like to keep this with no additional public API for now (other than supporting the deepcopy on norms and scales). In particular, I don't want to introduce a funkyLinearTransform that is basically anIdentityTransform.

That implies we have to makeIdentityTransform itself copyable, i.e. there has to be a change totransform.py. Thogh it can all be private. I have no strong preference concerning mixin into all scale transforms vs. a_CopyableTransform base class (partly also because it can all be kept private and so we can change that should the need arise).

I madeIdentityTranform copyable by adding a__deepcopy__ (and__copy__) to it, and removedLinearTransform fromtransform.py