Not sure, it's actually good to have that verbose reprs. On the other hand, someone had decided to have them by pulling in the str. So it's probably ok and at least not a change to the previous behavior..

OK, my quick study of this was that __repr__ is supposed to be the basic unambiguous representation of the object, and __str__ is supposed to be the user-facing object. So a __repr__ that returns __str__ is backwards, and we shouldn't have had that.

https://stackoverflow.com/questions/1436703/difference-between-str-and-repr

OTOH, I think I agree w/ @timhoffm that it seems strange to have such a verbose __repr__, and just have __str__ fall back on that. It seems that __repr__ should be a short unique identifier of the transform and __str__ should be the user-facing representation w/ all the indenting and representation of the matrices. But I'm not an expert on this. Just throwing it out there for discussion.

My personal two bits on this: I like the verbosity when doing print(transform) and it can be really helpful for debugging. It's also much easier to shorten the long form into a single line if needed than vice versa.
If other people have really strong objections, maybe there is another way to make the long form available?

Print will use the str form. I’m totally for the str form as the verbose version we have.

Ah, ok, so in which case would the __repr__ used then? What happens if you type artist.get_transform() + Enter in IPython, is this the __str__ as well?

90% sure thats the __repr__

Maybe we should just remove the __repr__ and let python use its default?

When is is used?

• ipython outputs and printing list elements use repr (probably because it's considered to be shorter than str).
• print() uses str.

as can seen in the following example which has the __repr__ deleted.

In [14]: ax.transAxes
Out[14]: <matplotlib.transforms.BboxTransformTo at 0x7f5dacff9ac8>

In [15]: print(ax.transAxes)
BboxTransformTo(
    TransformedBbox(
        Bbox(x0=0.125, y0=0.10999999999999999, x1=0.9, y1=0.88),
        BboxTransformTo(
            TransformedBbox(
                Bbox(x0=0.0, y0=0.0, x1=5.5, y1=4.5),
                Affine2D(
                    [[100.   0.   0.]
                     [  0. 100.   0.]
                     [  0.   0.   1.]])))))

In [16]: l = [ax.transAxes]

In [17]: print(l)
[<matplotlib.transforms.BboxTransformTo object at 0x7f5dacff9ac8>]

If that's not an option, at least, we should still rework __repr__ to either be a valid python expression (so that eval(repr(trans)) works, or alternatively enclose it in <...>. See https://docs.python.org/2/reference/datamodel.html?highlight=repr#object.__repr__

One thing that might be useful is that when you type artist.__dict__ to get get a a dictionary without the long transform chain out.

Supplying both __str__ and __repr__ was suggested by @QuLogic in #9421 (comment)

I think best would be to provide both, or to use repr(array) insde in both cases at least to make the expression valid.

OK, I think we agreed on the call that

1. __repr__ was unlikely to ever return a valid expression we can send to eval and hence should be enclosed in angle brackets.
2. that __repr__ should be a one-liner that tells us what the object is.
3. __repr__ should definitely not call __str__
4. that __str__ should be the pretty-print version, with the indentation implimented in Improve reprs of transforms. #9421.
5. I don't think there is anything at all incorrect about us supplying both, but

But this was just @efiring , @story645, and myself, so happy to dicsuss further, as that is hardly a quorum.

reference: https://docs.python.org/3/reference/datamodel.html#object.__repr__

See #11189 for the alternative as suggested by @timhoffm

Closing: alternative #11189 is merged.