Wonderful idea. I think the most common usecases could be implemented via gridspec.

Actually capturing the common use cases is quiete easy:

import matplotlib.pyplot as plt    
def parase_layout(s):
    s = [list(i) for i in s]
    s_T = transpose_list(s)
    n_cols = len(s[0])
    n_rows = len(s)    
    added_axes = {}    
    for i, row in enumerate(s):
        for j, ch in enumerate(row):
            if not ch in added_axes:
                width = n_rows-row.index(ch)-row[::-1].index(ch)
                height = n_cols-s_T[j].index(ch)-s_T[j][::-1].index(ch)
                added_axes[ch] = ((i,j), width, height)
    return added_axes, (n_rows, n_cols)

def transpose_list(l):
    return map(list, zip(*l))

def layout(s):
    d, (nr, nc) = parase_layout(s)
    gs = plt.GridSpec(nr, nc)
    for pos, width, height in d.values():    
        t = gs[pos[0]:pos[0]+height, pos[1]:pos[1]+width]
        plt.subplot(t)

s = ['AAB', 'AAB', 'CCC']
layout(s)

Do the values of the chars used to describe the layout matter? I.e. what about "MPL" to produce:

┌────────┐┌────────┐┌────────┐
│   M    ││   P    ││   L    │
│        ││        ││        │
│        ││        ││        │
└────────┘└────────┘└────────┘

What about non-latin characters, like Greek? "ΓγΔδ"
What about non-latin characters that don't have capital letters, like Chinese or Arabic? Seeing how in Chinese a single character can represent a whole word, or even more, it feels like the Chinese should write even better descriptors then what single chars allow for us in English.

@OceanWolf You're right, I don't seen any reason to not use utf8 character but the ascii restriction might make thing simpler in a first version.

For your example, I think it makes sense to write A,B,C = layout("MPL") or M,P,L = layout("MPL")

Great, I just love seeing code written as generically as possible. I see the hassles that firefox now have rewriting virtually their entire codebase to support languages that don't work right-to-left-top-to-bottom. It has taken them years to sort that out, and still it continues...

@mdboom Sorry, I missed you comment. I try to modify the MEP along with comments but then github interfaces hides outdated comments.

The A/a thing was suggested on the mailing list but I agree it's a bit strange. We could also have keyword arguments to specify where to add colorbars but I can't think of an intuitive syntax.

For your example, I would love to have:

  AaB
  CDE

  ┌───────┐┌─┐      ┌───────┐
  │ A     ││ │      │ B     │
  │       ││ │      │       │
  │       ││ │      │       │
  └───────┘└─┘      └───────┘
  ┌───────┐┌───────┐┌───────┐
  │ C     ││ D     ││ E     │
  │       ││       ││       │
  │       ││       ││       │
  └───────┘└───────┘└───────┘

If I understand how it works, the letters just group axes together with repeated letters indicating that that axes should occur larger. A "colorbar" axes (and I put that inverted commas because I don't think we should limit ourselves to just colorbars here) has a fixed width, i.e. it doesn't expand when the window expands, hence I don't see the need for letters for this type of axes.

How about we use the four operator symbols (+, -, /, *) to denote fixed width axes above, below, left and right respectfully. I would imagine that these axes should eat into the space assigned.

Hence ["AB/", "CD"] gives:

┌───────┐┌─┐┌────┐
│ A     ││ ││ B  │
│       ││ ││    │
│       ││ ││    │
└───────┘└─┘└────┘
┌───────┐┌───────┐
│ C     ││ D     │
│       ││       │
│       ││       │
└───────┘└───────┘

and ["A*B", "CD"] gives either what you outlined above, or the following:

┌────┐┌─┐┌───────┐
│ A  ││ ││ B     │
│    ││ ││       │
│    ││ ││       │
└────┘└─┘└───────┘
┌───────┐┌───────┐
│ C     ││ D     │
│       ││       │
│       ││       │
└───────┘└───────┘

Alternatively if we don't eat into the space, then ["A*B", "CDE"] gives:

  ┌───────┐┌─┐┌───────┐
  │ A     ││ ││ B     │
  │       ││ ││       │
  │       ││ ││       │
  └───────┘└─┘└───────┘
  ┌───────┐   ┌───────┐┌───────┐
  │ C     │   │ D     ││ E     │
  │       │   │       ││       │
  │       │   │       ││       │
  └───────┘   └───────┘└───────┘

But how would you specify horizontal colorbars ?
Maybe we abandon the idea of fixed width/height for a first implementation.

@rougier to get travis happy you should make sure that MEP28.rst is included in the toc tree in https://github.com/matplotlib/matplotlib/blob/master/doc/devel/MEP/index.rst

We are treating Sphinx warnings as errors when building the docs and this raises a not included warning.

Implenting fixed size axes is not too hard, the problem in matplotlib is more to choose the right size.

@rougier Horizontal axes would work exactly the same but using the + and - suffixes.

I think all this functionality is carried out by gridspec. I'm going to close due to inactivity. Feel free to re-open if this is inappropriate...

Do we want to merge not-implemented MEPs to keep a record of them?

The MEP process is a bit of mystery to me. But in this case it was never merged, so I assume it was never accepted.

In this case I think a little helper function could be written that wrapped GridSpec and add subplot to do what this MEP proposes. But maybe I’m missing something.