do you also want to support

x = ['AAB',     'CDB']

?

I suggested that and the argument@story645 had against it is that we should be encouraging long names like

x= [['map','histogram'],      ['time_series','time_series']]

but, that said, I suspect that could be implemented in the same pre-processing of the input that we would need to do for the auto-expanding logic.

but that still works, the point is to support List[str] vs List[List[str]]
I don't have a really strong opinion there though

if we support strings of arbitrary length, then how do we know that ["ABCD"] is ["A", "B", "C", "D"] vs ["AB", "CD"]?

What's the deterministic parse rule on that? Single letter equals 1 subplot?

Yeah, you either pass in a single stringor a list.

@staticmethoddef_normalize_grid_string(layout):return [list(ln)forlninlayout.strip().split('\n')]

So the point I could be clearer in making is the docs have to be 100 percent explicit that for string input, each character (excluding new lines and , ) is parsed as a subplot.

First of all - thanks for looking at that gist - would love to see this in matplotlib. I'd definitely encourage you to include the multi-line string approach because even though it's not super-generalisable it covers a very common use case for scientists preparing figures.

Two other random notes:

1. I updated my gist so that you can now use a '.' to indicate an empty axis because then I don't have to worry about spaces.
2. If you can find a good way to add the panel labels so that they align correctly withtight_layout even with different axis sizes without having to do any fiddling, that would be amazing. There might already be a good way of doing this but I've never figured it out. My current solution in the gist sort of works but is a bit hacky and the alignment isn't quite right (the letters should line up on the left not the right).

Thanks for all your work on matplotlib - it's very much appreciated.

constrained_layout handles empty gridspec slots by placing invisible axes in the empty slots.

Maybe go explicit for this case:

# subplotsfig1 = plt.figure(constrained_layout=True)ax_array = fig1.subplots(2, 2, squeeze=False)# subplot_mosaicfig2 = plt.figure(constrained_layout=True)ax_dict = fig2.subplot_mosaic(layout)

Probably should update Axes3D, too? Or just do aif hasattr(self, 'get_zlabel()') or something?

I think it would be better to have a custom repr on the Axes 3D than to inject knowledge of it here. The subtle but pervasive interconnection is one of the things that makes maintaining Matplotlib hard.

Agree w/ jody needs to be labeled Provisional & like needs "semantic/named" in here for the folks who don't know what patchwork is.

when possible avoid words like easily - either the example will seem easy to folks or it won't

in all honesty the single character version of the API horrifies me so I'd really rather we use the nested list "['clear name 1", "clear name 2"] version or at the least also highlight it in the what's new

From an API point of view I agree, but what I learned writing the tutorial is that the string based one is several times easier to use. Added an example of the list one to this.

I'm 👍 on empty_sentinel kwarg

ASCII art should be replaced withstring

It has typestr, but it has extra meaning (it shouldlook like the layout you want) which I think is captured by ASCII art. I don't like that it suggests only ASCII will work, but I don't think anyone would understand "unicode-art"?

I think art implies well art and that's kind of idiomatic/metaphorical when it's literally a string of characters.

not thrilled that all the docs need to be repeated here, is it so help? works

It is also a slightly different API because we also create the figure. Having the duplication is annoying, but I don't think there is a mechanical way to do the re-writing that is simpler in the long run that just having the duplicate text.

this makes the tutorial really really hard to follow along 'cause it's kinda magiking away the actual plotting w/ the axes. I think this tutorial would benefit from verbosity to make the two methods super clear.

I very much disagree on this. The point of this tutorial is to show how to use thesubplot_mosaic API to generate layouts of Axes. By putting the label is huge text in the middle it makes the mapping between the input thesubplot_mosaic and the layout clear. Doing actually plotting on the Axes will be distracting from the main goal.

I cry and get super-frustrated any time I see functions in the docs 'cause it requires me to keep a call stack in my head.
Also I think we have cross purposes here. theidentify_axes is good for showing howsubplot_mosaicworks because it prints the layout, yes. It's not great at showing how tousesubplot_mosaic because it abstracts away the usage of the axes which is integral to why I should use this method. What about a combination of identify_axes to put text in the background, but then put plotting on top.

I think this should have a simple example at the beginning in the "usual" workflow,including actual plot commands. Then this should be followed up with a simple example using this new method of creating the axes, again with the simple plot commands. After that, there is no need to keep showing plotting commands for showing the features of the method.

Conversely, docs that havealmost the same boiler plate repeated multiple times is also very frustrating to use because instead of "and a function is called" you have to mentally do the diff of 15 lines of code while scrolling between the examples to sort out what was actually changed. By putting the stuff that is the same in a function the signal to noise goes way up.

I'm not really convinced that this change adds anything, but I also don't think it does any harm.

I re-organized the tutorial to start with subplots + plotting -> list with nice names + plotting -> string short hand -> the extra kwargs ->

kw=dict(ha='center',va='center',fontsize=fontsize,color='darkgrey')fig,axd=plt.subplot_mosaic(layout,constrained_layout=True)axd['A'].text(0.5,0.5,"A",**kw)axd['B'].plot([1,2,3])axd['C'].hist(range(10)]axd.['D'].imshow([[1,2],[2,1]])

this is equivalent to

fig,axes=plt.subplots(nrows=2,ncols=2,constrained_layout=True)axes[0,0].text(0.5,0.5,"A",**kw)axes[[0,1].plot([1,2,3])axes[[1,0].hist(range(10)]axes.[1,1].imshow([[1,2],[2,1]])

Keep ABCD and just run the same code as above

I think there is value in changing the letters up make clear that there is no actual meaning in the values of the letters.

On more thought, we make that point later on, will change this to use D.

feedback at [mailing list/discourse/?]

The internet says this is an antipattern...

This is far from our only type-normalization on parsing input....

I choked on that, too. It harks back to my Perl days, thankfully long gone.

The choking episode was not fatal...

typo - layout is one word?