Note that we may want to deprecate the STOP code, which is documented as "not required and ignored" but actually causes the rest of the path to be dropped silently; it gets appended by cleaned() and caused an earlier version of this PR to break (because the STOP would then cause the rest of the concatenated path to be dropped).

This sounds like a dangerous change of semantics when using the proposed alternatives.

The thing with STOP would be a separate PR anyways, I'm just noting it here because I realized its nonobvious semantics in this PR.

This needs a rebase and it is not immediately clear that not callingmake_path_regular athttps://github.com/matplotlib/matplotlib/pull/14199/files#diff-d6593efaf6f4a6b9fb34f84bfa9964b5L3219 is ok (I think it just letsp.codes is None pass through?) so pushing to 3.3

rebased
did you meanhttps://github.com/matplotlib/matplotlib/pull/14199/files#diff-d6593efaf6f4a6b9fb34f84bfa9964b5L3126? (your link doesn't point to an use of make_path_regular) yes, I know just let path=None pass through as such instead of expanding it to its synonym [moveto, lineto, lineto, ..., lineto].

A couple thoughts

1. Removingmake_path_regular at patches.py:3190 is safe ONLY because the only place the arrow transmuters are used isget_path_in_displaycoord, which is only called bydraw, which immediately concatenates its outputs.
2. Concatenation makes this safe only because the logic ofmake_path_regular is already duplicated in.Path.make_compound_path (see path.py:338 inBezier/Path API Cleanup: fix circular import issue #16812 ).

Had I been more confident that rocking the waters with my own opinions on naming was okay, I would have proposed renamingmake_path_regular to.Path.ensure_codes in#16812 , since this states more clearly what the function is really doing. In particular, you want to usemake_path_regular whenever you want to make sure there are codes present (for example, this is important in.Path.make_compound_path, because without the explicitMOVETO at the start of each Path that is passed in, the compound path will not correctly be made up of multiple strokes).

My opinion is that the proposed replacement (.Path.cleaned(remove_nan=False)) does not accomplish the same goal as the deprecated function. However, if@anntzer is confident that concatenation is the only use case where you'd want to ensure codes exist, then I can rebase#16812 on top of this PR).

I clarified the deprecation note for make_path_regular to note that one may want to remove the final STOP.
I can't beconfident that concatenation is the only use case, but it's certainly the only use casein the library right now. Do you have other use cases in mind?

I can't beconfident that concatenation is the only use case, but it's certainly the only use casein the library right now. Do you have other use cases in mind?

Fair, I should have phrased this better. What I meant was something like, "as long as you guys agree that losing this functionality would hurt the users by taking away some use case I haven't thought of".

None of the use cases I was thinking of involve less than one stroke, it makes sense tomake_compound_path first anyway.

In related news, since you've also noticed thisSTOP issue and are recommending usage ofmake_compound_path, I've always wondered....shouldn'tmake_compound_path do something like (at the end of the current function)

last_vert,last_code=vertices[-1],codes[-1]vertices=vertices[codes!=self.STOP]codes=codes[codes!=self.STOP]iflast_code==self.STOP:vertices=np.append(vertices,last_vert)codes=np.append(codes,last_code)

to prevent internalSTOP codes after concatenating the paths?

I think we should just deprecate STOPs, unless there's a good reason to keep them (which I can't think of...).

I agree that STOP should be deprecated....but that seems out of scope of this PR, and until such day as it's actually done, it seems likemake_compound_path should be made to do the correct thing.

Do you want to PR that?

Sure!