Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
MEP30: Grid population strategies
Table of Contents:
- Detailed description
- Branches and Pull Requests
- Backward compatitiblity
Author: Paul Ganssle
Date: August 20, 2017
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
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-1, with the number of rows being either
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
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
SquarishStrategyobject could have options like
justificationwhich could include:
,'right'` - empty spaces either center the plots or leave them ragged-left or ragged-right
fill-grow'(names subject to change) - These would fill every column as "fully-justified", with
fill-spaceincreasing the interstitial space and
fill-growmodifying 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
6would return a 3x2 grid,
7would return a 7x1 grid, and
10would 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
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.
GridStrategybase class should be designed such that instances of
GridStrategycan be used to populate a grid.
GridStrategysubclasses should be provided that will cover the common use cases.
Squarish(name to be decided)
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)
Branches and Pull requests
- 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.