Ok. Looking at this, I think it is a viable alternative to #1326, so feel free to fire back any review actions.

Thanks,

See my comments in #1326 -- looks good to me

Thanks @ChrisBeaumont, very helpful.

@ChrisBeaumont wrote:

Some of the ugliness in that PR was in trying to put the transform=None functionality into factory methods like scatter and streamplot. Note that, in this PR, setting transform=None in those two methods still uses data coordinates.

My only concern with this is that it is technically new functionality that wasn't in v1.1.1. Given the late hour, I would rather not do that. Perhaps we should think more about this functionality and target it for v1.3 - potentially we could introduce a nicer syntax (maybe allow the use of transform='data' / transform='axes' / transform='device').

@mdboom , @dmcdougall et al. I think this is ready for merge.

Cheers,

The following code prints "True", and I think that is due to this change.
At least in v1.1, it prints "False", and it seems right to expect "False".
Is there a reason to explicitly call "set_trasnform" inside "get_transform"?

import matplotlib.patches as mpatches

p = mpatches.Rectangle((0, 0), 1, 1)

a = p.get_transform()
print p.is_transform_set()

At least in v1.1, it prints "False", and it seems right to expect "False".

Logically, I cannot see how can you get_transform if it is not set, so I see it as - "If you don't give me a transform in the first place, and you ask for my transform, I will set my transform to Identity and return it to you".

I've fixed problems relating with this change in streamplot & legend in the past, is there a specific case which is now not working for you?

Cheers,

I would say "implicitly set" the transform in this case. The original behavior which only sets the "_transform" attribute is okay, but setting the "_transformSet" attribute, I am not sure.

According to the documentation

    def is_transform_set(self):
        """
        Returns *True* if :class:`Artist` has a transform explicitly
        set.
        """

I am not sure if calling "get_transform" is considered to set the transform "explicitly".

The current behavior introduces a bug in one of my module. I can easily workaround this but want to make sure if calling the "set_transform" method (instead of setting "_transform" attribute directly) inside "get_transform" is a necessary change.

I would say "implicitly set" the transform in this case.

Ok, that is a reasonable definition.

I can easily workaround this but want to make sure if calling the "set_transform" method (instead of setting "_transform" attribute directly) inside "get_transform" is a necessary change.

There are tests that depend on it, although I think there are ways of implementing get_transform which will make the tests and your definition of is_transform_set compatible. There should be sufficient test coverage in this area to give yourself some confidence if you do decide to re-implement get_transform.

HTH

@pelson: my question is why, in the first place, you introduced this change.

-            self._transform = IdentityTransform()
+            self.set_transform(IdentityTransform())

I've spent a couple of minutes looking over this and it's not clear to me. I'll run the tests to see if there is a test which gets caught, otherwise I'd be fine with reverting it.

Out of curiosity: is there a compelling reason to distinguish between explicit and implicit transform setting? That seems like a particularly subtle and hard-to-enforce policy. My inclination would have been to change the documentation (remove "explicitly") instead of the code.

@ChrisBeaumont : When an artist is added to an axes, the transform of the artist is set to the data transform of the axes by default, unless the artist's transform attribute has been "explicitly set". And there are cases when we want to call the "get_transform" method before the artist is added to an axes (in this case, the method returns an identity transform). Still, when this artist is added to an axes later, its transform should be overridden to the data transform. Current code prevents this. So, as far as I can see, the documentation is right and the code needs to be fixed.

@pelson: My tests with the above line reverted passes all relevant tests (I have one fail not related to this). And I think we'd better not to change the original behavior of "get_transform" method. So, I would very much appreciate if you revert this change. Reverting this may break something, but I would say that something needs to be fixed, not the "get_transform" method.

Still, when this artist is added to an axes later, its transform should be overridden to the data transform.

There is a caveat to that - if you define transform=None in the Artist creation, you are explicitly saying that the Artist's transform is Identity. These cases are all tested in test_artist.py:test_patch_transform_of_none. I'm about to submit a PR for @leejjoon's suggestion I'd be really grateful if you could both look over it with your own perspectives to confirm it meets both of your expectations.

Thanks,

Nudge: #1790