Skip to content

Conversation

@timhoffm
Copy link
Member

@timhoffm timhoffm commented Jan 15, 2026

This extends Figure.add_axes() so that it works without parameters and creates a single subplot Axes. So far, you'd have to pass a rect tuple or and Axes.

In particular:

  • fig.add_axes() is equivalent to fig.add_subplot(); in the limiting case without parameters.
  • plt.figure().add_axes() creates the same figure and axes objects as fig, ax = plt.subplots()
  • plt.figure().add_axes() creates the same figure and axes objects as plt.axes()

Why is this addition reasonable?
This provides yet another way to create an Axes. We already have so many ways, doesn't this add more to the confusion?

The arguments are:

  1. Expected behavior: If I have an add_axes() function, it's natural to expect that a can add a "default" Axes with out having to specify additional parameters.

  2. API consistency: plt.axes() already has this behavior. By extending fig.add_axes() we gain identical behavior on both methods.

  3. One could argue that add_subplot() already does this, so people should use it instead. The point here is that I don't think we should stress formal distinction between subplot and Axes for one figure-filling Axes. In particular I would like to de-emphasize subplot as written in DOC: Tutorial on API shortcuts #30952 (comment)

    Edit Somehow the link to the comment does not work, but it's this one; please go there manually if needd:

    grafik

    This would also make the shortcut sequence from DOC: Tutorial on API shortcuts #30952 more consistent:

    • fig, ax = plt.subplots()
    • ax = plt.figure().add_axes()
    • ax = plt.axes()
      As soon as the function changes from potentially creating multiple Axes to creating only one Axes, we switch terminology from "subplots" to "axes".

Overall, since the ship on minimal axes creation API has sailed, adding one more way does not significantly worsen the complexity situation. But as a positive effect, we gain more consistency and can tell a better story on Axes creation using a subset of all that is possible.

@timhoffm timhoffm force-pushed the parameterless-add_axes branch 4 times, most recently from 79da667 to 15c3144 Compare January 15, 2026 13:28
@timhoffm timhoffm force-pushed the parameterless-add_axes branch from 15c3144 to e66c9b6 Compare January 15, 2026 13:29
@anntzer
Copy link
Contributor

anntzer commented Jan 15, 2026

If we're going that way (which I'm not really in love with, but sure), I think add_axes should gain support for the full set of add_subplot args (add_axes(gridspec[...]), add_axes(111), add_axes((1, 1, 1)) or add_axes(1, 1, 1) (preferably not both)). This way add_axes can just become the general axes addition method. Otherwise the difference between add_axes() and add_axes(any_arg) feels a bit jarring.

@timhoffm
Copy link
Member Author

That's indeed not an unreasonable idea. The kwargs of both functions are already identical. And in both cases the first argument defines where to put the axes. In that sense, a rect and a subplot are just different ways to define where.

My only caveat is conceptual. Is it desirable at all to create multiple subplots incrementally via separate calls? My mental model is (1) first create the complete arrangement of Axes (plt.subplots(), plt.subplot_mosaic()) and (2) then start filling them, because layout and data are separate concerns that I don't want to mix. But YMMV.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants