Skip to content

subplot(): incorrect description of deletion of overlapping axes in the docs #7393

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
anntzer opened this issue Nov 3, 2016 · 0 comments
Closed
Milestone

Comments

@anntzer
Copy link
Contributor

anntzer commented Nov 3, 2016

The docstring for plt.subplot states that

       Creating a new subplot with a position which is entirely inside a
       pre-existing axes will trigger the larger axes to be deleted::

          import matplotlib.pyplot as plt
          # plot a line, implicitly creating a subplot(111)
          plt.plot([1,2,3])
          # now create a subplot which represents the top plot of a grid
          # with 2 rows and 1 column. Since this subplot will overlap the
          # first, the plot (and its axes) previously created, will be removed
          plt.subplot(211)
          plt.plot(range(12))
          plt.subplot(212, facecolor='y') # creates 2nd subplot with yellow background

       If you do not want this behavior, use the
       :meth:`~matplotlib.figure.Figure.add_subplot` method or the
       :func:`~matplotlib.pyplot.axes` function instead.

(which I think is a rather silly behavior but whatever -- seems inherited from MATLAB, in fact).

The actual behavior (which is also MATLAB's behavior) is to delete any axes that overlaps the newly added axes, which can be easily checked from the code

    for other in fig.axes:
        if other==a: continue
        if bbox.fully_overlaps(other.bbox): # <-- here
            byebye.append(other)
    for ax in byebye: delaxes(ax)

and also by running e.g. plt.subplot(221); plt.subplot(335) (the first subplot does get deleted).

Making this a doc issue rather than requesting for the behavior to be changed because I don't think either behavior really makes sense anyways :-)

Noticed while investigating #6096 -- this is the mechanism that leads to one of the axes being deleted (note, though, that regardless of this, there still(?) seems to be an issue with incremental tight-layouting in #6096).

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

No branches or pull requests

2 participants