PR suggested by @anntzer

Note that this would not only be useful in itself, but would also fix a long-standing issue hinted at in

1. How does this relate to autolim parameter of add_collection()?

Places which used to call add_collection(..., autolim=False) should just set the collection's in_autoscale property to False before passing it to add_collection (and add_collection should be updated to take it that property into account).

2. This conceptually is similar to the visibility checks in relim(). It would be good to have both checks either inside the update*_limits or in relim() but not distributed over two places.

That's a bit tricky to do, as relim() is a public API but we should not modify the state of the artist depending on whether visible_only was passed to relim.

will work on it

(Note to self: once this is merged this can also be used to control autolimits behavior in axline() as mentioned in the side note of #15330 (comment)).

It was mentioned in #15967 that this method (which solves exactly a problem that I having been having) applies to both axes in a plot, but there may be times when you want to exclude autoscaling on one axis but allow it on another. In fact, there is some precedence for that independence, e.g. with the scalex/scaley parameters in plt.plot.

I see the point of being able to specify this per axis.

Not completely thought this through API-wise, but a axis parameter similar to the one in tick_params might be the way to go.

The input side of the API in clear and can be backwards ly, but what does the get side return? Do we want to do {'x': True, 'y': False}?

Ymmv but I think an (x, y) pair would be fine

Blind tuples are pragmatic, but can lead to confusion if we start to lose track of what they mean.

On the other hand, that ambiguity can be leverage to play nicely with polar plots.

If we go with a tuple / dict / whatever we should also extend it to 3D as well?

How about using a namedtuple?

On a bit more consideration, I think that a tuple is probably the best path. The artists don't actually know if they are in an (x, y), (r, \theta), (ra, dec), or (lat, lon) coordinate system, they just know they are in 2D (or 3D) so trying to same them will end up causing more issues because it will be wrong rather than ambiguous.

API proposal:

Setter

set_in_autoscale(False)  # for both axises
set_in_autoscale((False, True)) # for each axis s
set_in_autoscale((False, True, False)) # for 3D

Rationale: I find it more clear to have a single parameter that can be a scalar or a tuple compared to having variable number of arguments. In the latter case, we'd have to set_in_autoscale(*args) because you cannot have explicit arguments (set_in_autoscale(scalex, scaley)) and supporting a single value applying to all dimensions. But the single-parameter case is the primary usecase and excluding single dimensions is far more rare.

Getter

scalex, scaley = get_in_autoscale()
scalex, scaley, scalez = get_in_autoscale()

Per #15595 (comment) a simple tuple is good enough and saves the hassle of determining meaningful names, which can depend on the projection.

Internal representation

self._in_autoscale should always be a tuple with as many entries as dimensions in the plot (2D/3D). The expansion from scalar to tuple should be done in the setter.

@robmarkcole Sorry this fell under the table. Are you still interested in working on this?

Rebased to use this as the start of the implementation for #25139

Tasks:

• adopt tuple rather than a single bool
• move the autolim logic into the Artist classes.

@robmarkcole Do you mind if we work in this PR / on your branch? I would rather do so because it keeps the discussion in one place, but also completely understand if you no longer are interested in getting notified about this discussion!

This new property will be super useful! Could you explain the rationale for naming it in_autoscale instead of partly backward-compatible autolim from add_collections? I am implemeting autolim in geopandas and wondering if I should call it in_autoscale instead. Thanks!

Any updates on this PR? would be a very useful feature.

The following diagramm shows an outline of the limits-related call graph

Currently the update is mostly done through the Axes methods add_[Artist] --> _update_[Artist]_limits --> update_datalim. Though there are quite a number of special cases:

• _update_line_limits does not go through _update_datalim, but directly modifies dataLim.
• there is no _update_* method for Collections, instead add_collection directly calls update_datalim. Additionally, that is optional because add_collection has a kwarg autolim to decide whether data limits should be updated. Further speciality: Collections have a get_datalim method whereas in the other cases, the _update_[Artist] method must exctract the limits from the corresponding Artist.
• Images are special in that add_image does not do autoscaling, but imshow calls AxesImage.set_extent, which in turn calls update_datalim. There is also a _update_image_limits method, but this is not called when adding the image, only when doing a relim().

So overall every Artist is a special case 😲.

I believe we should consolidate the architecture before modifying the autoscale behavior. We can do this in multiple steps:

1. Investigate to remove the special cases: Can update_line_limits just call update_datalim? Can add_image call _update_image_limits?
2. I like the get_datalim method, as it's the responsibility of every Artist to know it's size in data coordinates. Every Artist that works with data should have this method, but it may return None. T.b.d. do we want to add a default impelmentation to Artist (which means also Figure grows this)? If not either we'd have to create the notion of DataArtist (either as base class or as protocol). I'm tempted to go with protocol because that is the least invasive.
3. Remove the _update_[Artist]_limits methods. add_[Artist] and relim() should call update_datalim(artist.get_datalim()).

To provide natural "in_autoscale" behavior, we'd need to take changes though Artist.set_in_autoscale into account. There are two ways: (1) Simple but expensive: set_in_autoscale() triggers a complete relim(). (2) Deferred limits update. Rearchitect futher so that data limits are calculated lazily. Basically autoscale would go through the artists and collect the limits.