Skip to content

Update legend loc default value in docstring #11517

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
Jun 29, 2018

Conversation

joelostblom
Copy link
Contributor

PR Summary

The default value for legends' loc parameter is stated to be upper right in the docstring, but it is actually read from the rcParam legend.loc. Only when the parent of the legend is a figure and the default rcParam is 'best', this is overwritten with 'upper right' since automated legend positioning is not implemented for figures. This can be confusing, as indicated by the two last comments here.

Ideally, I would like to add to this PR and make the difference between legends of figures and axes objects explicit, e.g. default: :rc:`legend.loc` ('best' for axes, 'upper right' for figures), but I noticed elsewhere in the documentation that the default parameter values are not explicitly stated, so I didn't want suggest an inconsistent change here.

An alternative would be to not silently change the default value for figures, but instead raise the same warning as when loc='best' is specified manually, also when the rcParam is set to 'best' (so just remove lines 485-486).

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 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

@@ -111,7 +111,7 @@ def _update_bbox_to_anchor(self, loc_in_canvas):


_legend_kw_doc = '''
loc : int or string or pair of floats, default: 'upper right'
loc : int or string or pair of floats, default: :rc:`legend.loc`
Copy link
Member

Choose a reason for hiding this comment

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

Can you please also state the default rc value like this:

default: :rc:`legend.loc` = 'best'

Copy link
Member

Choose a reason for hiding this comment

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

Ah, didn't read your text completely.

We would like to add the rc default values in the future (there's a pending PR #10714 for this)
See section rcParams in https://10714-1385122-gh.circle-artifacts.com/0/home/circleci/project/doc/build/html/devel/documenting_mpl.html?highlight=documenting#writing-docstrings.

It's true that this is a bit more involved in the case of legend. I think your propoal

default: :rc:`legend.loc` ('best' for axes, 'upper right' for figures)

is reasonable.

I wouldn't want a default issueing a warning that it will be changed. This is rather confusing. Of course, the best way, would be to have 'best' also for figures. Since we don't have that for now, the different defaults make sense.

Copy link
Contributor Author

@joelostblom joelostblom Jun 27, 2018

Choose a reason for hiding this comment

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

Great thanks for letting me know about that, including the default param value is a welcome change, looking forward!

I wasn't sure which line break strategy to use for the parentheses here. I went with the same approach as in figure.py lines 695-696, as this was the only other occurrence of a line breaking default: I could find. It does make the line quite long compared to other lines in the docstring, so I can add a line break instead if you prefer. I just need advice on how much I should indent the line after the break.

@tacaswell tacaswell added this to the v2.2.3 milestone Jun 29, 2018
@tacaswell tacaswell merged commit c928022 into matplotlib:master Jun 29, 2018
@tacaswell
Copy link
Member

Thanks @joelostblom !

dstansby added a commit that referenced this pull request Jun 29, 2018
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