Summary

For now, this is a ticket to collect my thoughts. It's not completely thought though and therefore not yet actionable.

Data limits are stored in Axes.dataLim and updated via a push-mechanism (plotting functions that add artists also update the data limits). This has several disadvantages:

• Changes to the data within an Artist cannot be automatically be picked up; one needs to explicitly call Axes.relim.
• Syncing dataLim for shared axes is tedious
• The concept does not work well with clearing shared axes ([MNT]: Define Axes.clear semantics #28851 (comment)).

Proposed fix

We should rearchitect data limit handling:

Break the strong coupling between Axes and data limits: Create a _DataLimits class that does all the limit related operations:

class _DataLimits:
    def __init__(axes):
          self.axes = axes
          self.datalim = BBox.null()
    
   def relim(...):
         # pull pull code from Axes.relim in here

and remove it from Axes

class AxesBase:
    def __init__(...):
        [...]
        self._datalimits = _DataLimits(self)
        # remove self.dataLim

    @property
    def dataLim(self):
        return self._datalimits.dataLim

    @dataLim.setter
    def dataLim(self, lim):
        self._datalimits.dataLim = lim

    def relim(...):
         self._datalimits.relim(....)

When we have managed this, we can improve:

• DataLimits could handle multiple Axes. This allows much better handling of sharing We can then have one DataLimits instance, which collects data information from multiple Axes. This single DataLimits instance is used on all shared Axes. (Note: We likely have to have separate DataLimits objects for x and y to support all kinds of sharing)
• We can make DataLimits lazy - they are just called from the Axes now. All the state handling is encapsulated in DataLimits. (Possibly, combined with a refactoring so that we can query Artists for their data limits. - Then _DataLimits just has to loop over all artists on all handled Axes and collect the limit information.