Skip to content

[New Feature] Insert color fill parameter to Boxplot instead of using 'patch_artist' #17959

Open

Description

@lfenzo

Feature Request

I'm new to matplotlib and I don't know if there is a specific reason for the boxplot fill coloring to be the way it is. I only wonder if it could be done in a more straight forward manner than what is shown in here.

The idea for this "new feature" would be to use a color parameter that recieves either a list of supported colors or a single color (e.g. color = 'red') that specifies the colors to be applied to each one of the boxplots in the ax.

How it is currently done

import matplotlib.pyplot as plt
import numpy as np

data = [np.random.normal(0, std, 1000) for std in range(1, 6)]

box = plt.boxplot(data, notch=True, patch_artist=True)

colors = ['cyan', 'lightblue', 'lightgreen', 'tan', 'pink']
for patch, color in zip(box['boxes'], colors):
    patch.set_facecolor(color)

plt.show()

The idea for this 'New Feature'

import matplotlib.pyplot as plt
import numpy as np

data = [np.random.normal(0, std, 1000) for std in range(1, 6)]

colors = ['cyan', 'lightblue', 'lightgreen', 'tan', 'pink']

# or maybe 'c = colors', 'face_colors = colors'...
plt.boxplot(data, notch=True, colors = colors)

plt.show()

Any thoughts on this idea?

Matplotlib version

  • Operating system: Windows 10 2004
  • Matplotlib version: 3.2.2
  • Matplotlib backend (print(matplotlib.get_backend())): TkAgg
  • Python version: 3.7.7
  • Jupyter version (if applicable): 2.1.5
  • Other libraries:

Activity

  1. changed the title [-]Insert color fill parameter to Boxplot instead of using 'patch_artist'[/-] [+][New Feature] Insert color fill parameter to Boxplot instead of using 'patch_artist'[/+] on Jul 18, 2020
  2. timhoffm commented on Jul 18, 2020

    @timhoffm
    Member

    Thanks for your proposal.

    Generally, I agree that it should be simpler to set the facecolor.

    Setting a single color

    You can already do plt.boxplot(data, notch=True, patch_artist=True, boxprops={'facecolor': 'red'}). This is slightly simpler than setting on the returned patch. But still not simple enough. Most of the time, users should not need to define patch_artist. We could change the default to patch_artist='auto' which would use patches if any of the given parameters (to be checked if boxprops is the only relevant) requires patches.

    This would also open the way of maybe defaulting or always using patches. I don't see a benefit in boxes being drawn with Line2D.

    Using a colors parameter directly is tempting, but IMHO not precise enough. Boxes are complex objects and there is merit in precisely speifying "facecolor of the box" using the current syntax boxprops={'facecolor': 'red'}.

    Setting different colors per box

    I'm -0.5 on this. We don't have per-element settings for any of the styling parameters. This would add additional complexity to an large API.

  3. anntzer commented on Jul 18, 2020

    @anntzer
    Contributor

    I would think that there's certainly merit in switching to always using patch_artist=True (with the relevant deprecation period, yada yada). My guess is that we simply started using Line2D, and then at some point it was realized that Patches are (nearly) strictly more powerful, at which point both options were kept for backcompat. But always using Patches is just simpler.

  4. timhoffm commented on Jul 18, 2020

    @timhoffm
    Member

    Will have to think about the least-breaking way to migrate. Since patch_artist changes the style in a non-trivial way, just changing the default would possibly break a lot of existing code.

    Note to self: seaborn always uses patch_artist=True.

  5. jklymak commented on Oct 3, 2021

    @jklymak
    Member

    Was this closed for some reason? I think the general agreement was that it is a reasonable feature. I'll take the liberty of re-opening...

  6. reopened this on Oct 3, 2021
  7. github-actions commented on Aug 11, 2023

    @github-actions

    This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

  8. added
    keepItems to be ignored by the “Stale” Github Action
    and removed
    status: inactiveMarked by the “Stale” Github Action
    on Aug 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    API: changesChanges to the public API, typically requiring deprecation.New featurekeepItems to be ignored by the “Stale” Github Action

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions