Since no user has reported that this is broken for more than 3 years, I’m considering removing that parameter. The naming is confusing and the bug can be regarded a very hard deprecation 😏 . If we want such functionality, we could either re-introduce it under a better name such asnaxes, or consider whether there is a better and more flexible API altogether: For examplen_rows_cols could take a 2D bool array, specifying at which positions one wants Axes.

I don't really mind either way. However, if you're going to refactor this, I wonder if it would be better to instead have aarrange_grid() that takes the output of Figure.subplots() or Figure.subplot_mosaic() (i.e. an array or a dict of axes) and sets the locators on them as needed and optionally adds colorbars. This would allow a more orthogonal API (think "composition over inheritance", even though there isn't inheritance here) -- in particular, you wouldn't need provide rect, ngrids, share_all/share_x/share_y (you'd just read these off the axes that are passed to you.

I guess the required signature would be

defarrange_grid(axes,# array or dictaxes_pad=0.02,aspect=???,label_mode="L",# not even clear this is needed; label_outer() could be enoughcbar_mode="each"/"single"/"edge"/"none",# "none" case covers the plain Grid()# followed with the cbar_foo kwargs): ...

How is that different than layout='compressed'?

I actually agree with the comment in#27963 that we should just get rid of axes_grid and promote layout="compressed" as much as possible. (I guess the "different-sized images" case could perhaps be handled nowadays via box_aspect? Does CL know anything about that?)

CL knows about width- and height ratios. However it doesn't know about the aspect ratio of the axes inside, and is best suited to axes that don't have aspect constraints. (You can write the problem including aspect constraints but the optimization goes from 2n to n^2 and becomes very slow.)

I'd not be against adding a new method to the top level library that does a grid of fixed aspect axes like this. But we should carefully decide how it is different than what we already have and if it's worth it, versus letting the folks who need this do a bit of fussing with width and height ratios.

(I don't have strong feelings about axes_grid; this PR was mostly motivated by fixing a regression I caused some time ago...)

I still want to decide whether we use the fact that this parameter was not working for a long time to remove or rename it.

Since this was found internally and not by users, we have no indication that somebody is using it, so no need to hurry and fix it.

hi, can i solve this issue?

This is a solution proposal that needs decision from core developers. You cannot help here.

@timhoffm Can we reach a decision on this? I still mildly prefer restoring support for ngrids (perhaps prior to larger changes later) but don't really mind if we decide instead to just drop it. But the current situation (a non-working but documented kwarg) just seems the worst.

I'm still for deprecate and note that this has not been working anyway. Nobody has complained about this the last 4 years. If you think the feature is helpful let's reintroduce it right away under a new meaningful name such asn_axes.

Edit: Or fix and@rename_parameter which is effectively the same. - I just don't want that people are using the unintuitive namengrids.

OK, renamed.

Syntax seems broken somewhere.

oopsie. refixed.