Repository navigation
[MNT]: new public method to help title positioning #29385
Description
Summary
- The change that broke [Bug]: title position incorrect for polar plot #29381 would have been fine if the logic that calculates
topwithinAxes._update_title_positiononly needed to work for ordinaryAxesinstances. - Cartopy has artists separate from the
XAxisandYAxiswhich must be considered for title placement. Currently, it does that by overriding_update_title_position. Overriding a private method is not ideal, neither is repeating some of the code that is already in the parent method.
Proposed fix
Factor out a public method that returns top. Making it public means it can safely be overridden in subclasses such as PolarAxes and Cartopy's GeoAxes. Knowing it can/should be overridden in subclasses means that in the parent Axes we can use the most efficient approach that works for Axes.
Reacted by hannah
Activity
timhoffm commentedon Jan 6, 2025
First step: The optimization from #28300 was only valid for the case of rectilinear Axes. We can add that optimization right now if we limit it to
Ax.name == “rectilinear”and keep the old behavior for all other cases. This is the 80/20 solution (good gain with little effort). And I believe we should do this.Possible further steps:
We generally have a backward compatibility problem with the optimization wrt subclasses. We don’t know whether they are ok with the optimization. To not break them, the optimization has to be opt-in, which also means we have to keep the unoptimized code around (at least for a time). I’m a bit hesitant to force subclasses to copy that code and provide their own implementation. Maybe we should keep it and classes can set a flag to use the optimized version? So far/with that we wouldn’t need a dedicated function.
The function comes into play where considering ticks and axis label are not enough - like in cartopy. It can indeed help 3rd party Axes subclasses. But IMHO we can decouple the topics. The function does not help with the (non-)optimization topic as it is not backwards compatible/ convenient for subclasses that don’t introduce extra artists.
rcomer commentedon Jan 6, 2025
A simpler solution for the Cartopy case might be to add a public attribute to
Axes, which is a list1 of "extra artists" that should be considered for the title. ThenAxes._update_title_positionjust needs to loop through and callget_tightbboxon each to updatetop. It's slightly complicated in Cartopy's case because the relevant text objects are children of a container artist: they do not exist until the first call todraworget_tightbboxon the parent and might move on the next call. I note that_update_title_positionis called before the artists are drawn. Perhaps we could just use the tight bbox of the parent though - we did make that calculation more efficient not long ago. 🤔Footnotes
or other iterable ↩
rcomer commentedon Mar 15, 2026
I'm going to close this one. The polar issue is fixed. As for Cartopy, this is by no means the only private API it is reaching into - I only brought it up here because of the parallel with the polar issue.