Whats wrong with:

fig = plt.figure(figsize=(6,12)) # tall figure
ax = fig.add_subplot(1, 2, 1, projection='polar')
im = ax.pcolormesh(t, r, c.T)
fig.colorbar(im, ax=ax, shrink=0.2)

If you want to get fancy, you can figure out the shrink...

I'm actually surprised that there is no way to set the projection except via add_subplot.

Hi jklymak, there is nothing wrong with shrink. But still the problem is how to figure out the shrink, which I think axes_grid1.axes_size can do. Honestly, it should be not too hard to do without axes_grid1.axes_size.

I think fig.colorbar internally uses GridSpec, so perhaps just a different way to do it. But I still think axes_grid1.axes_size should handle different projections properly.

Very true. I generated a lot of map plots (which are usually rectangular) with Cartopy, and the axes_grid1 doesn't work, probably due to the lack of support of "map_projection." I ended up tweaking 'shrink' argument. By the way, you can actually set projection for a bunch of plots at once using f, axarr = plt.subplots(2, 2, subplot_kw=dict(projection='polar')). For me the issue is, I want different projections in different panels, so add_subplot seems to be the only way out... (and again shrink)

I'm not a huge fan of axes_grid1, so I think it'd be nice to see any functionality like this in fig.colorbar.

The problem, as it often is, is interactivity. Yes, I think its possible to make the colorbar match the size of the parent axes using the aspect ratio of the plot as it currently is set. But if the user changes the aspect ratio of the plot (by adjusting the x or y-lims or zooming) then does the colorbar change size? That sort of interactivity isn't impossible, but starts to make the code pretty complicated. Personally, I'd rather someone composing a figure just eyeball a good-looking colorbar shrink and aspect, rather than introduce a slew of hooks where the axis for the colorbar gets adjusted on the fly. But if someone wants to work on it, I'm sure a PR would be welcomed.

@jklymak This seems like the sort of problem that the constraints based layout should be able to address.

@tacaswell Yes, I think so. Its been a while (;-)) so I'd have to check and see what it does already. Part of the impetus for #9855 was for the constrained layout to know how big the axes wanted to be. The question will be (once we get there) is what the default should be (shrink is proportional to original or modified Axes position) and how to implement choosing.

The gist link above is dead, so let's just move the full discussion to #3286, as I think(?) all the relevant info is over there.