I'd suggest showing what this does with an example either in the GitHub pr description, or ideally in the gallery

I'm not really sure if I need to add a new test or just modify an exisiting one(test_hist_stacked_bar) in test_axes.py

I guess there are two things here:

1. Add/modify an example in the gallery to illustrate how it is used. (Will be easier for the reviewers to get an idea of how it is used etc.)
2. Add a test to get the code coverage up and make sure no one breaks it later. Maybe there is some old example that one can "hi-jack", but otherwise create a new test with all the bells and whistles turned on.

pinging@story645 for review. The failing tests are unrelated

also needs updated documentation that the patch properties are now vectorized (@timhoffm any concerns here?)

What should we be concerned about? We already have vectorizedlabel andcolor. It's only fair to vectorize these insidehist() as well. This should be documented with**kwargs (can't immediately suggest, because that part has not been touched in the PR). Something like:

        **kwargs            `~matplotlib.patches.Patch` properties. The following properties additionally            accept lists of property values, one element for each dataset:            *edgecolors*, *linewidths*, *linestyles*, *hatches*.

This should also get a what's new entry.

What should we be concerned about? We already have vectorized label and color.

My bias is vectorize everything so I don't have concerns, but in the past for some vectorization discussions there have been concerns about the tradeoffs. But if there isn't opposition, awesome!

I don't see any drawbacks forhist()

So we are planning to vectorizeall parameters of Patches? Like joinstyle, capstyle etc.

So we are planning to vectorize all parameters of Patches? Like joinstyle, capstyle etc

Not at this time w/ the current architecture, especially because nobody has asked for those.

Codecov is acting fishy, it passed once and failed again after squashing. Anything else to add/change?

As of the last commit, this behavior is consistent for all histtypes unless mentioned otherwise:

• Ifedgecolor, facecolor and color are mentioned, color is completely ignored.
• Ifedgecolor and color are mentioned, color is applied to only the faces and edgecolor to the edges.
• Iffacecolor and color are mentioned, color is applied to only the edges and facecolor to the faces.
• Iffacecolor and edgecolor are mentioned, edgecolor is applied to edges, and facecolor is applied to faces.
• Ifonly color is mentioned, the face is colored for all filled histograms, and only the edge is colored for unfilled histograms with the values incolor.
• Ifonly facecolor is mentioned, the face is colored for all filled histograms with the value infacecolor, and the edges are colored with the default color cycle for unfilled histograms.
• Ifonly edgecolor is mentioned, the face is colored by the default color cycle for all filled histograms, and the edge is colored with the values inedgecolor for all histograms.
  I feel this is the required behavior, but I am unsure if the color setting for the kwargs can be written more concisely.
  Let me know if I should start writing tests based on this structure.

@Impaler343 I started trying to flow chart that and then realized it's probably clearer as a table. Let me know if this jives with what you're saying:

Have bolded the corrected ones

I'm unable to fix CircleCI errors for docs. Could someone help me out?

Hi, so the error is in your what's new:

/home/circleci/project/doc/users/next_whats_new/histogram_vectorized_parameters.rst:47: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/circleci/project/doc/users/next_whats_new/histogram_vectorized_parameters.rst:51: ERROR: Unexpected indentation.
/home/circleci/project/doc/users/next_whats_new/histogram_vectorized_parameters.rst:64: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/circleci/project/doc/users/next_whats_new/histogram_vectorized_parameters.rst:68: ERROR: Unexpected indentation.

error:https://app.circleci.com/pipelines/github/matplotlib/matplotlib/31532/workflows/2533c013-7833-4d0c-ae72-dead7c7fbc76/jobs/83481?invite=true#step-113-207133_109
rendering:https://output.circle-artifacts.com/output/job/2c962d26-1c66-49dd-a987-e5bf25c8fcbe/artifacts/0/doc/build/html/users/next_whats_new/histogram_vectorized_parameters.html

Ok it turns out the vectorization ofcolors is somewhat incomplete:

• When we pass None, calls the color cycle, which is fine.
• When we pass a list of valid colors, it uses them, which is also fine.
• When we pass alist of Nones or even if one value in the list is None, it throws an error saying invalid RBGA argument. What can we do in this situation? Should we say that we use the colour cycle even if one value in the list is None and raise a warning? Or call the color cycle's next color whenever a None is encountered in a list? Or simply assume that the user will not pass a list like color= [None, "green", None] and ignore this check?

or simply assume that the user will not pass a list like color= [None, "green", None]

I think this input is ambiguous cause it can mean either:

1. opt those two lines into the color cycle such that it maps to ['C0', "green", 'C1']
2. set both lines to the same default ['C0', "green", 'C0']

So I think it's ok to error out (unless/until someone comes around expecting 1 or 2) but we should maybe special case and have a better error message, like if not all(colors) (if any are NaN) "Ambiguous color specification: colors in the list may not be None"

Or something like that.

The added lines have all been covered, codecov seems to still fail

Cause I think this maybe got lost, I was suggesting that this construction makes the skip case clearer:

forpatch,lblinitertools.zip_longest(patches,labels):ifnotpatch:continuep=patch[0]kwargs.update({'hatch':next(hatches),'linewidth':next(linewidths),'linestyle':next(linestyles),'edgecolor':next(edgecolors),'facecolor':next(facecolors),            })p._internal_update(kwargs)iflblisnotNone:p.set_label(lbl)forpinpatch[1:]:p._internal_update(kwargs)p.set_label('_nolegend_')

#28533 reminded me that this should get a versionadded directive

https://matplotlib.org/devdocs/devel/api_changes.html#announce-new-and-deprecated-api

The doc build failure could be fixed by rebasing onmain to get fixed CircleCI, but I built it locally and confirmed it builds, so I'm not going to wait for that, and just merge.

I'm so glad that this finally got merged! Thank you for the timely reviews

Thanks for keeping up with all the reviews!