• Status
• Abstract
• Detailed description
• Implementation
• Branches and Pull Requests
• Backward compatitiblity
• Alternatives

Author: Paul Ganssle

Date: August 20, 2017

Discussion

This MEP would add a mechanism for creating a grid of subplots based on the number of axes to be plotted and a strategy for how they should be arranged, with some sensible strategy as the default.

It is often the case that you have some number of plots to display (and this number may be unknown ahead of time), and want some sensible arrangement of the plots so that they are all roughly equally aligned. However, the subplots and gridspec methods for creating subplots require both an x and a y dimension for creation and population of a grid. This MEP would allow users to specify a strategy for the creation of a grid, and then specify how many axes they want to plot, and they would get back a collection of axes arranged according to their strategy.

Issue #8997, which first proposes this concept, includes a proof of concept for a "squarish" strategy, which arranges plots in alternating rows of length x and x-1, with the number of rows being either x or x-1 (i.e. the grid is never more than 1 plot wider than it is long, or vice versa), with some logic about how best to symmetrically arrange the deficient rows. The code is here, accompanied by a gallery of plots generated by this strategy. Some basic examples:

This makes use of a GridStrategy object, which populates a GridSpec. In general, this concept can likely be implemented as a layer of abstraction above gridspec.GridSpec.

Some basic strategies that would be good for an initial first release:

• "Squarish" (name subject to change) - As implemented in the demo code above - currently this is centered, but the base SquarishStrategy object could have options like justification which could include:
  • 'center' (default), 'left', 'right'` - empty spaces either center the plots or leave them ragged-left or ragged-right
  • 'fill-space' and fill-grow' (names subject to change) - These would fill every column as "fully-justified", with fill-space increasing the interstitial space and fill-grow modifying the width of the plots themselves to fill the row.
• "Rectangular" - Similar to "Squarish", this would find the largest pair of factors of the number of plots and use that to populate a rectangular grid - so 6 would return a 3x2 grid, 7 would return a 7x1 grid, and 10 would return a 5x2 grid.

Since many of these grid strategies would likely have at least some asymmetries, a mechanism for transposing any grid structure should be implemented in the base GridStrategy object.

Currently the MEP is limited to 2-dimensional grid arrangements, but a "nice-to-have" might be a higher-order API for GridStrategy that also allows for the proliferation of additional figures (e.g. "if I have more than 10 axes to plot, split them up as evenly as possible among n / 10 different figures"). This would be no harder to implement in terms of the creation of such strategies, but may be harder to work with since it would necessarily spawn axes across multiple figures.

• An abstract GridStrategy base class should be designed such that instances of GridStrategy can be used to populate a grid.
• Standard GridStrategy subclasses should be provided that will cover the common use cases.
  • Squarish (name to be decided)
  • Rectangular
• A basic function should be created that populates a gridspec from the number of plots and an object (e.g. subplots_from_strategy(n, grid_strategy, fig=None, **kwargs)).
• Wrapper functions for the standard subclasses should be created (e.g. square_layout(n, fig=None, **kwargs), rectangle_layout(n, fig=None, **kwargs)) that doesn't require instantiation of the explicit object.

All names above are provisional and subject to discussion.

(Not explicitly stated, but documentation and tests should accompany each of these Implementation steps)

• None

• None

• Issue #8997 - Proposal: Grid arrangement by number of plots

This would be implemented entirely on top of GridSpec and other existing subplot technologies. As a new feature, it will have no impact on existing features and is thus 100% backwards compatible.

No alternatives currently proposed.