Thanks for the fast work@nbarlowATI and for checking this works for the example in the issue. I'm unsure whether passing a single string will work at the moment. Could you check what happens if you passhatch="\\"?

This will also need some tests. Please seehere for general guidance on testing. You might also like to look at the tests added at#24470, where a similar change was made for thepie method.

Please mark this as "ready for review" when you are ready (things marked as draft often get overlooked). In the meantime, if you need help, feel free to ask questions here. Or you may prefer to ask them in ourincubator gitter room.

It'll also need a whats new example - what you have here is fine and you can also use the what's new in#24470 as an example.

ETA: also I'm psyched, this is great and we should vectorize all the things 😄

I was thinking perhaps this change is a good chance to introduce the following API (provided this is clear and acceptable):

• ax.stackplot(hatch="x"): singlestr gives result as we currently have (one big hatching over all data)
• ax.stackplot(hatch=["x"]): onestr defined in alist will use this onestr and vary the density (like what I showed in the issue) so e.g. if there are 4 datasets in the data, the hatchings should bex,xx, ...xxxx
• ax.stackplot(hatch=["x", "\\", "//", "-"]): list ofstr, the code cycles through the list

ax.stackplot(hatch=["x"]): one str defined in a list will use this one str and vary the density (like what I showed in the issue) so e.g. if there are 4 datasets in the data, the hatchings should be x, xx, ... xxxx

I understand why you're asking for this but I'm concerned this is a bit magic cause this is not a thing we do for any variables (list of color vary by density). Also if there was support for this, it'd have to work for all the places that take a list of hatches.

And I wonder if this would be better achieved via custom hatch objects?

hatch=DensityHatch('x') which returns an iterator of increasing density - which actually may work currently given our API doesn't really care what type of iterator hatch is?

ax.stackplot(hatch=["x"]): one str defined in a list will use this one str and vary the density (like what I showed in the issue) so e.g. if there are 4 datasets in the data, the hatchings should be x, xx, ... xxxx

I understand why you're asking for this but I'm concerned this is a bit magic cause this is not a thing we do for any variables (list of color vary by density). Also if there was support for this, it'd have to work for all the places that take a list of hatches.

And I wonder if this would be better achieved via custom hatch objects?

hatch=DensityHatch('x') which returns an iterator of increasing density - which actually may work currently given our API doesn't really care what type of iterator hatch is?

No problem. I was just throwing the idea for the debate.

I'm very much in favour of continuous improvement so even if there's a chance my proposal would be considered for implementation but hindered the current work, it's probably best to get out the current change (support for list of hatches) and then go back to the other ideas in the next iterations...

I added a test intest_axes.py that compares a stackplot with a list of hatching styles with the result of usingfill_between with the same data and hatching styles.
I also added a "what's new" entrydoc/users/next_whats_new/stackplot_hatch.rst that demonstrates the use of the hatch list.
Happy to add any other tests and/or examples that people think would be useful (now I'm getting the hang of this :) )

last thing left is fixing the stubtest by adding this variable - which I think isNone | List[str] | str ? - to the type stub

Thanks! Re: rebasing, it would be great if one of you could do it - I'm away for the next few days (but I could also do it when I'm back...)

This will also need squashing down to one commit if you are confident to do so, otherwise we can handle that on merge.

Edit: oops I see you already discussed that.

Hi, I'm back online now, and happy to have a go at the rebase. Just to confirm, is the idea to both:

• Rebase such that the commits here appear after the current state ofmain, i.e.git rebase upstream/main
• Squash all the commits related to this change into one, usinggit rebase -i
  ?
  (Or is there a single rebase command that does both of these?)
  If so, I can give it a go.

Squash all the commits related to this change into one, using git rebase -i

This one please! Since there are no conflicts between your branch andupstream/main, the ordering of your commits vsupstream/main's commits do not matter.

We have some guidance here if you need it
https://matplotlib.org/devdocs/devel/development_workflow.html#rewrite-commit-history

Don't add complication you don't need of course, butgit rebase -i upstream/main is the command I always use.

Many thanks@rcomer and@story645 for all your help with this!!!
I believe the commits are now successfully squashed into one.