Allow sharex/y after axes creation. #15287

anntzer · 2019-09-18T10:45:03Z

This intentionally does not allow unsharing or changing the shared axes,
as there are bigger questions on the API there (#9923 and issues linked there).

The API is named Axes.sharex() to allow for a later Axes.unsharex(),
though (set_sharex() would be fine, but set_unsharex()? or perhaps
set_sharex(None), though). Happy to hear suggestions.

An example use case is creating a grid with subplots(), but with
custom sharing relationships between the subplots -- e.g., sharex/sharey
across all, except the first row of axes which only shares x with their
column and the first column which only shares y with their lines.

PR Summary

PR Checklist

Has Pytest style unit tests
Code is Flake 8 compliant
New features are documented, with examples if plot related
Documentation is sphinx and numpydoc compliant
Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

jklymak

Overall this seems a useful API though I suspect we haven’t thought through how it will be used. Allowing sharing to be toggled like this seems like it will be ripe for misunderstandings. Could use some examples of why you think this is useful

jklymak · 2019-09-18T13:50:26Z

lib/matplotlib/axes/_base.py

+        """
+        Share the x-axis with *other*.
+
+        This is equivalent to passing ``sharex=other`` when constructing the


This docstring could be more explicit and non circular. For instance the verb to share would indicate that self shares with other, whereas the exact opposite happens. Further passing sharex=other calls this function so I don’t think it’s very helpful to say that this function is the same as that and expect the user to ferret out the behaviour

"self shares with other, whereas the exact opposite happens"
What do you mean by "opposite"? Isn't sharing symmetrical? (well perhaps not deep in the implementation details, but from the user PoV it is)

I meant in everyday English the transitive verb “to share” means one person shares Something with another

Can you propose an alternate wording here?

Sorry, the main point is that saying ax.sharex is "Equivalent to passing sharex=other when constructing..." is a circular doc, because when you construct, you call ax.sharex. This function ideally would define what ax.sharex does explicitly.

Right now the docs of sharex (as kwargs to the Axes constructor) are

sharex, sharey : `~.axes.Axes`, optional The x or y `~.matplotlib.axis` is shared with the x or y axis in the input `~.axes.Axes`.

which is not much better :/ I agree this can be improved, but is arguably a separate issue?

The docstring defines what the function does for the user, and one of our main problems with "share" is that people don't know what it means and even in the history of the code base different definitions have popped up. Right now I'm not 100% sure what this PR changed and I think it should be defined clearly, in plain English, what calling this function will do.

ax0 = (some axes) ax1 = fig.add_subplot(...) ax1.sharex(ax0)

is equivalent to

ax0 = (some axes) ax1 = fig.add_subplot(..., sharex=ax0)

Now it is true that what the latter does is not really well documented either, but the doc available for ax1.sharex(ax0) is, well, exactly the same.

anntzer · 2019-09-18T14:04:37Z

I'm explicitly not allowing toggling, or changing who you share with, just going from "not-shared" to "shared". Indeed, allowing unsharing makes the problem much more complex.

The use case hinted above is:

  A A A
B X X X
B X X X
B X X X

Each A plots the distribution (histogram) of variable a in conditions a1, a2, a3; each B plots the distribution of variable b in conditions b1, b2, b3, and each X plots the joint distribution (scatter plot). Here you want to sharex across rows and sharey across columns, except that the first row does not share y's and the first column does not share x's (let's say you don't want to normalize your histograms).
Right now if you want to do this you basically need to give up on subplots() and manually add axes in a loop while keeping track of who to share with what -- and that info needs to be passed immediately.
With the PR here, you can start by calling subplots(), then create the required share-linkages.

jklymak · 2019-09-24T17:33:54Z

I understand your example, but it would be helpful if you actually provided one in the PR.

anntzer · 2019-09-25T11:24:18Z

Do you mean one as comments in the code? (where?) in the commit message?

jklymak · 2019-09-25T14:18:38Z

I meant as an example in the example folder

anntzer · 2019-09-26T12:47:45Z

Sure, added a simple example.

efiring · 2019-10-07T02:38:14Z

First thoughts on this:

The API, with a simple sharex() method, is reasonable. I would not advocate prepending set_. More descriptive alternatives would be sharex_with() and sharex_from(). The latter has the advantage of noting that info (objects to be shared) will come from the argument, not go to it.
It seems like unsharing could be added by supporting the None argument, and replacing the shared objects with deep copies of them; but I haven't looked at this in detail.
Leaving aside the unsharing, which I agree does not have to be addressed here, I think the present approach would work fine when used early--immediately after Axes creation--but inevitably users will find ways to make it surprise them. For example, if two Axes are created, each is called with set_aspect(1, adjustable='datalim'), and then some time later they are shared, the problem won't be caught until draw(), when apply_aspect() is called.

anntzer · 2019-10-07T05:50:39Z

I guess I'm +0.5 on sharex_with() and +0.25 on sharex_from() (both are better than sharex()), let's see what others think.

What about adding something like

Note that this method is only intended to be called immediately after the axes has been created; unexpected behavior may occur if the axes already has its own aspect ratio, formatters, or locators set up.

to the docstrings? (I don't really intend to support "later" calls with this PR anyways.)

efiring

There might be unintended consequences, but let's try it.
Approved, subject to rebase.

This intentionally does not allow unsharing or changing the shared axes, as there are bigger questions on the API there. The API is named `Axes.sharex()` to allow for a later `Axes.unsharex()`, though (`set_sharex()` would be fine, but `set_unsharex()`? or perhaps `set_sharex(None)`, though). An example use case is creating a grid with `subplots()`, but with custom sharing relationships between the subplots -- e.g., sharex/sharey across all, except the first row of axes which only shares x with their column and the first column which only shares y with their lines.

anntzer · 2020-04-07T22:26:16Z

rebased

efiring · 2020-04-08T07:27:09Z

We seem to be getting a systematic failure--not just on this PR--in the macosx build on Travis, in test_bbox_inches_tight_raster[pdf], an image comparison failure.
In addition there are the two circleci docs failures here. Any idea what is going on? @QuLogic?

QuLogic · 2020-04-08T08:36:38Z

macOS failure is #17065; doc failure is just spurious inability to download a Sphinx inventory.

jklymak reviewed Sep 18, 2019

View reviewed changes

anntzer force-pushed the lateshare branch 3 times, most recently from 850d310 to f1ed957 Compare September 26, 2019 13:39

jklymak approved these changes Oct 1, 2019

View reviewed changes

jklymak added this to the v3.3.0 milestone Oct 1, 2019

jklymak added the topic: geometry manager LayoutEngine, Constrained layout, Tight layout label Oct 1, 2019

jklymak assigned efiring Oct 1, 2019

anntzer force-pushed the lateshare branch 2 times, most recently from 1abd103 to b57a4da Compare January 23, 2020 23:22

anntzer mentioned this pull request Feb 28, 2020

axes collage #16603

Merged

13 tasks

efiring approved these changes Apr 7, 2020

View reviewed changes

anntzer force-pushed the lateshare branch from b57a4da to 83c2d7b Compare April 7, 2020 22:26

efiring merged commit 9085810 into matplotlib:master Apr 8, 2020

anntzer deleted the lateshare branch April 8, 2020 16:56

This was referenced Jun 24, 2020

Share and unshare axes after creation. #9923

Closed

Matplotlib 3.3 has post-hoc axis sharing mwaskom/seaborn#2147

Closed

pierre-haessig mentioned this pull request Nov 12, 2022

Use sharex=True in plotting seasonal decomposition statsmodels/statsmodels#8514

Closed

anntzer mentioned this pull request Apr 11, 2023

shared twinned subplots: support ax.twinx(sharey=...) / ax.twiny(sharex=...) #8392

Closed

anntzer mentioned this pull request Apr 11, 2023

Move towards having get_shared_{x,y}_axes return immutable views. #21584

Merged

7 tasks

rdg-netra mentioned this pull request Jun 6, 2024

[Bug]: removing already extablished axis sharing #28345

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow sharex/y after axes creation. #15287

Allow sharex/y after axes creation. #15287

anntzer commented Sep 18, 2019

jklymak left a comment

jklymak Sep 18, 2019

anntzer Sep 26, 2019

jklymak Sep 26, 2019

anntzer Sep 26, 2019

jklymak Sep 26, 2019

anntzer Sep 26, 2019

jklymak Sep 26, 2019

anntzer Sep 28, 2019

anntzer commented Sep 18, 2019

jklymak commented Sep 24, 2019

anntzer commented Sep 25, 2019

jklymak commented Sep 25, 2019

anntzer commented Sep 26, 2019

efiring commented Oct 7, 2019

anntzer commented Oct 7, 2019

efiring left a comment

anntzer commented Apr 7, 2020

efiring commented Apr 8, 2020

QuLogic commented Apr 8, 2020

Allow sharex/y after axes creation. #15287

Allow sharex/y after axes creation. #15287

Conversation

anntzer commented Sep 18, 2019

PR Summary

PR Checklist

jklymak left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

anntzer commented Sep 18, 2019

jklymak commented Sep 24, 2019

anntzer commented Sep 25, 2019

jklymak commented Sep 25, 2019

anntzer commented Sep 26, 2019

efiring commented Oct 7, 2019

anntzer commented Oct 7, 2019

efiring left a comment

Choose a reason for hiding this comment

anntzer commented Apr 7, 2020

efiring commented Apr 8, 2020

QuLogic commented Apr 8, 2020