René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Support simple axes shares in subplot_mosaic","articleBody":"\u003c!--\r\nWelcome! Thanks for thinking of a way to improve Matplotlib.\r\n\r\n\r\nBefore creating a new feature request please search the issues for relevant feature requests.\r\n--\u003e\r\n\r\n### Problem\r\n\r\nI 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).\r\n\r\n(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.).\r\n\r\nHowever, `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)...\r\n\r\n\u003c!--\r\nProvide a clear and concise description of the problem this feature will solve. \r\n\r\nFor example:\r\n* I'm always frustrated when [...] because [...]\r\n* I would like it if [...] happened when I [...] because [...]\r\n* Here is a sample image of what I am asking for [...]\r\n--\u003e\r\n\r\n### Proposed Solution\r\n\r\n... 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...)\r\n\r\nLabeling 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.\r\n\r\n\u003c!-- Provide a clear and concise description of a way to accomplish what you want. For example:\r\n\r\n* Add an option so that when [...]  [...] will happen\r\n --\u003e\r\n\r\n### Additional context and prior art\r\n\r\n\u003c!-- Add any other context or screenshots about the feature request here. You can also include links to examples of other programs that have something similar to your request. For example:\r\n\r\n* Another project [...] solved this by [...]\r\n--\u003e\r\n","author":{"url":"https://github.com/anntzer","@type":"Person","name":"anntzer"},"datePublished":"2020-08-20T09:50:46.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":9},"url":"https://github.com/18305/matplotlib/issues/18305"}