I expect that the option of chopping up each level of the stack into N disconnected fill_betweens is not an option because it will break back-compatibility of the return type?

I am very concerned about the "coupled kwargs" here. That is, the meaning (or if we pay attention to!) user input depends on the values of other kwargs. This sort of coupling is (in my experiance) one of the things that makes APIs hard to use and remember (because you not only have to remember what the inputs are, you have to remember exactly how they affect each other).

@tacaswell

I am very concerned about the "coupled kwargs" here.
...

I agree with you on that. The arguments are definitely convoluted now.

I think the issue is that the real problem lies is that the anti-aliasing creates artifacts when there is a zero-width polygon. This can be fixed by settingwhere,interpolate andedgecolor but that is somewhat of a "hacky" fix.

So ideally, the user should never worry abouthide_empty.

The issue seems to be quite well known and appears in a bunch of different issues (see e.g.#9574). This is not a matplotlib error but rather a bug on the side of the renderer.
Usually this is solved by settinglw > 0 andedgecolor='face'. However, in the example shown in the description this won't work.

So there won't be a way to fix the underlying issue.

I think I have an idea how to solve this issue and also circumvent the whole interferingkwargs problem:

If we allowwhere to be a list, we can pass it element-wise tofill_between.interpolate=True andedgecolor='face' can be passed as normal.

It would look like:

where=kwargs.pop('where',None)ifhasattr(where,'__len__'):iflen(where)!=len(stack):raiseValueError("where has to have the same length as y")else:where=len(stack)* [where]

and then

coll=axes.fill_between(x,stack[i, :],stack[i+1, :],where=where[i],facecolor=color,label=next(labels,None),**kwargs)

@tacaswell, are you happy with this solution?

are you happy with this solution?

It will have to be done carefully to not break the case where someone passed in a 1d where and expects it to be re-used for each of the fill_betweens. We have a number of APIs that will do this automatic broadcasting / inference so it would fit in well with the rest of the library and user expectations, but that also means we are aware of how messy they can get ;)

Would it be easier to check for0s in the input rather than for equality in the stack?

Yep that sounds good. Could you guide me towards an implementation of the automatic broadcasting / inference? Def gonna be messy if I try to come up with something myself :D

Checking for0s in the input is certainly easier. I would leave this to the user, so that they can do callstackplot likeplt.stackplot(x, y, colors=colors, where=(y!=0)), interpolate=True, edgecolor='face'.
Since this is now kind of "hidden" I would maybe add this example somewhere? Maybe inexamples/lines_bars_and_markers/stackplot_demo.py?

Given that we do not have to worry about unit support onwhere, you may be able to directly usenp.broadcast_to(where, np.shape(y)).

Ok so I have overhauled this whole PR as discussed above.stackplot now has one extra parameterwhere that is passed to elemten-wise to the individual calls offill_between.
Where can be either a bool, an array of length N or an array of shape (M, N): M being the number of tracks and N their length.

I think this solution is way better than the old one. Now we don't have competing kwargs, andwhere is used in a similar way tofacecolor andlabel. And original issue (#22393) is solved when callingstackplot(x, y, where=(y!=0), color=color, edgecolor='face', interpolate=True)

@tacaswell, do you mind having a look at the recent changes? I think that could be a small PR that doesn't break anything else but solves the issue

@tlkaufmann I apologize that this fell off my radar!

I took the liberty of rebasing and squashing this down to one commit (twice ❤️ flake8). If you want to push additional commits to this branch, before you do anything else do:

git remote updategit checkout stackplot_PR# where YOUR_REMOTE_NAME is the name of the remote that points to your forkgit reset --hard YOUR_REMOTE_NAME/stackplot_PR

which will discard (😱) any local commits and replace them with the current state of this branch. If you do not do this the old commits will be resurrected!

I'm going to leave one comment about the docstring which my request some additional work.

@tacaswell , thanks for getting back to me.]

Rebasing was a good idea as the git history was kind of a mess :D I added a warning to check whetherinterpolate=True is set ifwhere is notNone and also resorted the imports inlib/matplotlib/tests/test_axes.py to fit with the main branch as my IDE automatically re-ordered these.

The errors in the above checks seem to be irrespective of my changes

I took the liberty of rebasing this.

This probably needs a whats new and/or an example of how to use this to get the desired effect.

Pushed to 3.8 as Tim makes a good point about the API and the tests are failing.

@tlkaufmann any interest in taking this up. It seems your implementation was close, but maybe we do not want to expose all of the complication ofwhere, which seems reasonable to me. I'll move to draft until we hear from you, and I'll mark as orphaned, but feel free to unmark and move out of draft.