Aller au contenu
login
arrow_backRetour aux issues
matplotlib/matplotlib #18305

Support simple axes shares in subplot_mosaic

ecoDébutant New feature Good first issue

descriptionDescription

### 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" (https://github.com/matplotlib/matplotlib/pull/16603#issuecomment-593006244)... ### 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
codeOuvre sur GitHub