Repository navigation
Support simple axes shares in subplot_mosaic #18305
Description
Activity
I'm half-way tempted to remove "good first issue" until we actually decide this is a good idea...
I'm ok with the proposal. It's a clear specification and can help for simple layouts. I don't expect it to be useful for really complex layout, but it would do still do something reasonable there.
I'm currently reading the documentation and I didn't know, until now, that it does not have sharex/sharey parameters. Will look at the code a bit and send a PR if I figure it out.
Is it still ok to work on this issue?
Hey @Selich are you still planning to work on this?
- Started working on it but, unfortunately, do not have any free time these couple of months. You can start working on it.…On Fri, Jan 8, 2021 at 2:13 AM Aitik Gupta ***@***.***> wrote: Hey @Selich <https://github.com/Selich> are you still planning to work on this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18305 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACM45BTTBDATN7OTNK4CPMLSYZL4VANCNFSM4QF3TBJA> .
9 remaining items
Can I take a stab on the remaining work (currently at SciPy 2023 sprint)?
would it be very unwieldy to support dicts? That's more or less a simplified version of your comment: (ax["A"].sharex([ax["B"], ax["C"]])), -> {'A': ['B', 'C']}
Is the key:value adding anything? I think a list of lists would also do the job sharex=[[A, B], [C, d]] without making you pick one of the axes as "special" to act as the key.
We can carry code like (which assumes we have done the key -> axes object mapping already)
for ax_list in sharex: head, *rest = ax_list for ax in rest: head.sharex(ax)
in subplot mosaic. We already have a very similar loop for the "all" case.
Realizing the share docs are just confusingly written. Still think it would be a good idea to generalize share but that can be a separate discussion then.
Never mind, that loop won't work if I'm testing this right: (using mpl-dev environment)
In [4]: fig, axes = plt.subplots(4) In [6]: axes[0].sharex(axes[1]) In [7]: axes[0].sharex(axes[2]) --------------------------------------------------------------------------- ValueError Traceback (most recent call last) Cell In[7], line 1 ----> 1 axes[0].sharex(axes[2]) File ~\Projects\matplotlib\lib\matplotlib\axes\_base.py:1313, in _AxesBase.sharex(self, other) 1311 _api.check_isinstance(_AxesBase, other=other) 1312 if self._sharex is not None and other is not self._sharex: -> 1313 raise ValueError("x-axis is already shared") 1314 self._shared_axes["x"].join(self, other) 1315 self._sharex = other ValueError: x-axis is already shared
You have to do the reverse:
In [8]: fig, axes = plt.subplots(4) In [9]: axes[0].sharex(axes[2]) In [10]: axes[1].sharex(axes[2])
Sharing is implemented asymmetrically/directionally (see also #30159 (comment)). This is an implementation detail and not logically necessary.
IMHO we should remove that and only store the shared state in the grouper. See #30159 (comment)
Reacted by hannahHi, I’m interested in helping with simple axes sharing in subplot_mosaic. I’d first compare the existing sharex/sharey handling and add focused tests for the requested layout cases before proposing the smallest API change. Is this issue still open for community work?
Hi, I'd like to work on this issue as my first contribution. Is it still available ? If so, Could you please assign the issue to me? Thank you !
We do not assign issues. Please see our contribution guide https://matplotlib.org/devdocs/devel/contribute.html#managing-issues-prs
Problem
I realized that subplot_mosaic() is quite nice even to create single row or single column layouts if you were previously going to stuff the result of subplots() in a dict anyways (or use hardcoded indices, in which case a dict may be more robust if you may (in some later iteration of the code) add axes somewhere in the middle).
(Side points: Also, this avoids running into the subtle bug, when writing axs = subplots(n), of the case n = 1 where axs is squeezed into a single axes (yes, I know, the fix is to pass squeeze=False...) Single column is slightly trickier than single row (subplot_mosaic([[name] for name in names])) but heh.).
However, subplot_mosaic() does not allow axes sharing. Yes, I've even argued against it in the original PR on the grounds of "too complicated" (#16603 (comment))...
Proposed Solution
... but we could at least support the simplest case(s), as in subplots(): sharex/sharey=True/"all" (this is completely unambiguous: share all axes -- "all" is a synonym from subplots() that we probably want to keep for consistency), and possibly "row"/"col" (I'd say two axes (which may have various spans) are in the same row for sharing purposes if they both begin on the same row and end on the same row, which seems the most useful definition)? We should be careful, when checking for True, to actually check for that value (or 1, or np.bool(True)), and not for general truthiness, so that we don't get boxed in later if we decide we do want to support passing in complex sharing specs (e.g. via dicts, as proposed in the original PR thread). (I'm still against that complexity, at least for now...)
Labeling as good first issue as I don't think there's too much complexity or API design space here, although we still need to decide whether this is a good idea or not.
Additional context and prior art