Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Clean up get_proj() docstring (used view_init docstring as reference) #16996

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 4 commits into from
Apr 5, 2020

Conversation

rdimaio
Copy link
Contributor

@rdimaio rdimaio commented Apr 1, 2020

PR Summary

Clean up the get_proj() docstring so that it follows the same format as view_init(elev=None, azim=None).

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

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.

Thanks for looking into this.

Actually, I'm wondering why elev, azim and dist are mentioned here. They are only remotely related to the method.

@rdimaio
Copy link
Contributor Author

rdimaio commented Apr 2, 2020

Thanks for looking into this.

Actually, I'm wondering why elev, azim and dist are mentioned here. They are only remotely related to the method.

Hi, thanks for the comment. I am not sure either; it almost seems like it was mistakenly copied over from the view_init docstring (at least regarding elev and azim). Should I remove them from the get_proj docstring altogether? The final docstring would end up simply saying "Create the projection matrix from the current viewing position."

@timhoffm
Copy link
Member

timhoffm commented Apr 4, 2020

The final docstring would end up simply saying "Create the projection matrix from the current viewing position."

That's better than the current gibberish. 😄

Even better would be to describe the projection matrix. IMHO it's not self-explanatory How does it look? How is it used? But I don't insist on that extension.

@rdimaio
Copy link
Contributor Author

rdimaio commented Apr 4, 2020

The final docstring would end up simply saying "Create the projection matrix from the current viewing position."

That's better than the current gibberish. smile

Even better would be to describe the projection matrix. IMHO it's not self-explanatory How does it look? How is it used? But I don't insist on that extension.

Thank you for your input! I can take a better look later this month; here's the docstring with just the method description for now.

@@ -946,11 +946,7 @@ def set_proj_type(self, proj_type):
def get_proj(self):
"""
Create the projection matrix from the current viewing position.
Copy link
Member

Choose a reason for hiding this comment

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

If the docstring is just a single line, we use the more compact notation:

def _get_proj(self):
    """Create the projection matrix from the current viewing position."""

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for your patience. I updated the docstring to follow the specified notation; I also updated another method's one line docstring in the same file which wasn't following the notation. There is a docstrings I am not sure about, as it seems incomplete:

   def _3d_extend_contour(self, cset, stride=5):
        """
        Extend a contour in 3D by creating
        """

Copy link
Member

Choose a reason for hiding this comment

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

Indeed that does seem to trail off mid-sentence. You can either push more commits to this PR to try and finish the sentence or do that in a second PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can have a look at it later and open a second PR 😄

@tacaswell tacaswell added this to the v3.3.0 milestone Apr 4, 2020
Look for unit *kwargs* and update the axis instances as necessary

"""
"""Look for unit *kwargs* and update the axis instances as necessary."""
Copy link
Member

Choose a reason for hiding this comment

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

This exceeds the line limit of 79 chars and thus flake8 complains. One option would be less wordy:

"""Update the axis instances based on unit *kwargs* if given."""
OTOH it would be even better to document the parameters.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for pointing that out! I changed the docstring so that it does not exceed the line limit as you advised. In the following days I will make another PR to expand on the doc for _3d_extend_contour and for _process_unit_info so that the parameters are documented.

@timhoffm timhoffm merged commit 8162641 into matplotlib:master Apr 5, 2020
@timhoffm
Copy link
Member

timhoffm commented Apr 5, 2020

Thanks, and congratulations on your first contribution to Matplotlib! We hope to see you back some time.

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.

4 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.