Skip to content

Store dash_pattern as single attribute, not two. #21050

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 1 commit into from
Dec 16, 2021

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Sep 11, 2021

Dash offset and pattern are always used together, so just store them as
single attributes on lines and patches, instead of separate ones.

PR Summary

PR Checklist

  • Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (run flake8 on changed files to check).
  • New features are documented, with examples if plot related.
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).
  • Conforms to Matplotlib style conventions (install flake8-docstrings and run flake8 --docstring-convention=all).
  • New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).

# this is needed scaling the dash pattern by linewidth
self._us_dashSeq = None
self._us_dashOffset = 0
self._us_dash_pattern = (0, None) # offset, dash (unscaled)
Copy link
Member

Choose a reason for hiding this comment

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

I‘m inclined to use a namedtuple instead of the comment for semantic clarity.

Copy link
Member

Choose a reason for hiding this comment

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

At that point, should it be a dataclass so that it can eventually carry documentation/the linestyle docs can be pushed there?

Copy link
Contributor Author

@anntzer anntzer Sep 12, 2021

Choose a reason for hiding this comment

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

You could write self._dash_pattern = DashPattern(0, None) but I would argue that this is actually worse and still needs a comment (or DashPattern(offset=0, dashes=None) to not need a comment), as it is less clear that we're just taking two values and not doing anything fancy with them (whereas a constructor could do arbitrary things with its arguments).
Additionally, we'd never actually use the .offset and .dashes accessors, which removes the main benefit of having named fields (well, _scale_dashes could take a packed dashpattern rather than an unpacked dashpattern as parameter, but that doesn't seem like a big deal).
Using a dataclass would also makes things harder on the C (agg) side for parsing (well, it's always doable, but you get a bunch of PyObject_GetAttrString and PyFloat_AsDouble and error and refcount management and whatnot, versus PyArg_ParseTuple which does many things for you).

@@ -603,8 +598,9 @@ def draw(self, renderer):
if not self.get_visible():
return
# Patch has traditionally ignored the dashoffset.
Copy link
Member

Choose a reason for hiding this comment

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

Why?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

"backcompat".

@jklymak
Copy link
Member

jklymak commented Sep 23, 2021

I'm not really sure this is better than just having two attributes? *-Expanding the tuple all the time doesn't improve readability.

@anntzer
Copy link
Contributor Author

anntzer commented Sep 24, 2021

I think(?) storing as a single tuple makes it clearer that the two things are closely related and should basically always be considered together.

@tacaswell
Copy link
Member

This PR is affected by a re-writing of our history to remove a large number of accidentally committed files see discourse for details.

To recover this PR it will need be rebased onto the new default branch (main). There are several ways to accomplish this, but we recommend (assuming that you call the matplotlib/matplotlib remote "upstream"

git remote update
git checkout main
git merge --ff-only upstream/main
git checkout YOUR_BRANCH
git rebase --onto=main upstream/old_master
# git rebase -i main # if you prefer
git push --force-with-lease   # assuming you are tracking your branch

If you do not feel comfortable doing this or need any help please reach out to any of the Matplotlib developers. We can either help you with the process or do it for you.

Thank you for your contributions to Matplotlib and sorry for the inconvenience.

Copy link
Member

@timhoffm timhoffm left a comment

Choose a reason for hiding this comment

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

I'm still a bit uneasy about using a simple tuple because that is not self-explanatory; in contrast to two variables or a namedtuple. But maybe ok because the only usages are definitions (with comment) and unpacking into functions.

Dash offset and pattern are always used together, so just store them as
single attributes on lines and patches, instead of separate ones.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants