Tim Hoffmann

> `bar(h)` also uses the `tick_label` and `label` semantics so this would be consistent with that. This is a very good point. Let's go with that. > I have a...

Yes, we could extend this to something like an ArtistContainer, which itself can support (parts of) the Artist API. But let's start small.

I just realized that we have `Container`, which could be a complimentary approach. However, I think that a data class is the more simple and understandable approach (-> public concept)....

Put to draft to rethink this approach vs. Container. Feedback welcome.

> I'm torn if the deprecation note on this is exuberant enough for the scale of the change. I believe most affected users will learn from the runtime warning anyway....

To access other titles use ``` ax.get_title(loc="left").set_size(50) ```

@szwang1990 sorry my bad, I didn't check my recommendation carefully enough. You're right that `get_title()` only returns strings and thus does not help here. Can you explain your use case...

@jklymak I don't think that set/get_title_left/right is really much of a help it would shorten @tacaswell's solution from ``` ax.set_title(ax.get_title(loc='left'), loc='left', **kwargs) ``` to an only marginally better ``` ax.set_title_left(ax.get_title_left(),...

> Yes, I'd misunderstood what `get_title` does. I did too, see above. :roll_eyes: > I think 2, publicly exposing `title.title_left/right`, is probably fine for this use case. The only thing...

I suggest to make `_left_title` public under a property (name t.b.d. e.g. `left_title_text` / `left_title_artist` / `left_title_obj`) and same for `title`. Then discourage (deprecate `title`) because it's confusing.