Thanks to visit codestin.com
Credit goes to github.com

Skip to content

fix bug where make_compound_path kept all STOPs #16822

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 19, 2020

Conversation

brunobeltran
Copy link
Contributor

PR Summary

Fixes underlying issue in make_compound_path that would keep .Path.cleaned from being a drop-in replacement for bezier.make_path_regular (#14199).

A path we create by concatenating many paths should never have internal STOPs, as STOP is documented to mark the end of the entire path.

Long term solution is probably to deprecate Path.STOP, but then this code can be easily deleted as it is self-contained, and the new test will signal.

PR Checklist

  • Has Pytest style unit tests
  • Code is Flake 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@tacaswell tacaswell added this to the v3.3.0 milestone Mar 18, 2020
@@ -341,6 +342,16 @@ def make_compound_path(cls, *args):
codes[i:i + len(path.codes)] = path.codes
i += len(path.vertices)

# remove internal STOP's, replace kinal stop if present
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: final

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also not bother with restoring the final STOP given that it doesn't matter and we may deprecate STOPs.
And even though this is clearly a bugfix, it also changes the behavior of the function wrt STOP codes, so it may change it a tiny bit more (in a less observable fashion! the final STOP doesn't matter, unlike the middle ones) to keep the implementation simpler.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that is acceptable, then I will document it and go with ignoring all STOPs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

at least for me, it seems ok.

@tacaswell
Copy link
Member

I am concerned about deprecating a path code given how far down the stack this is.

Would it be simpler to replace the STOP with MOVETO in the concatenated codes?

@tacaswell
Copy link
Member

Notionally 👍 to this change, concerned about deprecating STOP, holding off on approving given there are 3 proposed implementations ;)

@anntzer
Copy link
Contributor

anntzer commented Mar 18, 2020

this is still not deprecating STOP, just changing the behavior of make_compound_path.

@brunobeltran
Copy link
Contributor Author

3 proposed implementations

You mean #16822, #16812, and #14199? It may not seem like it due to the large overlap in conversation, but these are actually totally independent, incremental improvements to the path/bezier interface :)

@brunobeltran
Copy link
Contributor Author

brunobeltran commented Mar 18, 2020

I will also point out here for the record that the "truly correct" behavior is something like

for path in args:
    first_stop = next((i for i, c in np.ndenumerate(path.codes) if c == cls.STOP), None)
    num_codes = len(path.codes) if first_stop is None else first_stop
    codes[i:i + num_codes] = path.codes[:first_stop]
    i += len(path.vertices)

but making this solution actually work adds a disproportionate amount of code complexity for a corner case (concatenating multiple paths with internal STOPs) that it's not clear we need to support (whereas concatenating a bunch of paths that correctly end in stop should surely work correctly).

@brunobeltran
Copy link
Contributor Author

Sorry for force-push. Accidentally pull'd in from master, had to rebase to trigger CI to finish running.

brunobeltran added a commit to brunobeltran/matplotlib that referenced this pull request Mar 18, 2020
brunobeltran added a commit to brunobeltran/matplotlib that referenced this pull request Mar 18, 2020
@timhoffm
Copy link
Member

Force-pushing to your own PR branch is perfectly fine.

Copy link
Contributor

@anntzer anntzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

anyone can merge postci.

@timhoffm timhoffm merged commit 1632a53 into matplotlib:master Mar 19, 2020
@timhoffm
Copy link
Member

Thanks @brunobeltran!

brunobeltran added a commit to brunobeltran/matplotlib that referenced this pull request Mar 19, 2020
brunobeltran added a commit to brunobeltran/matplotlib that referenced this pull request Mar 19, 2020
brunobeltran added a commit to brunobeltran/matplotlib that referenced this pull request Mar 20, 2020
brunobeltran added a commit to brunobeltran/matplotlib that referenced this pull request Mar 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants