Skip to content

Make functions param to secondary_x/yaxis not keyword-only. #28133

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
Apr 25, 2024

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Apr 24, 2024

I suspect the parameter was made keyword-only because the originally planned signature (#11859) was secondary_xaxis(location, forward=..., inverse=...) where the keywords actually add some semantics (though that signature overall seems worse); however, for a single functions parameter, having to type an extra functions= in the call doesn't help the reader much (either they know what secondary_x/yaxis does, in which case the explicit kwarg doesn't matter, or they don't, in which case the kwarg name hardly helps)... and is a bit annoying. See the modified gallery entry, for example.

PR summary

PR checklist

@github-actions github-actions bot added the Documentation: user guide files in galleries/users_explain or doc/users label Apr 24, 2024
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.

Ok. Stubs need to be updated.

I suspect the parameter was made keyword-only because the originally
planned signature was `secondary_xaxis(location, forward=...,
inverse=...)` where the keywords actually add some semantics (though
that signature overall seems worse); however, for a single `functions`
parameter, having to type an extra `functions=` in the call doesn't help
the reader much (either they know what secondary_x/yaxis does, in which
case the explicit kwarg doesn't matter, or they don't, in which case the
kwarg name hardly helps)... and is a bit annoying.  See the modified
gallery entry, for example.
@anntzer
Copy link
Contributor Author

anntzer commented Apr 24, 2024

oops, done.

@oscargus
Copy link
Member

Is an API change note worthwhile? If not, anyone can merge.

@oscargus oscargus added this to the v3.10.0 milestone Apr 25, 2024
@timhoffm
Copy link
Member

An API change note is not neccessary since we're only relaxing the API. It's also not very helpful: Nobody will read through API changes, see this and take an action ("Finally, this is not kwonly anymore - I go through my code and change to positional use" is not gonna happen). So the note would mostly be noise. The only possible benefit would be a .. versionchanged:: note in the function, so that a user could decide to write backward-compatible code. - But then again. I don't think, we have such information consistently. I would not bother.

@QuLogic QuLogic merged commit 91234e2 into matplotlib:main Apr 25, 2024
43 of 44 checks passed
@anntzer anntzer deleted the saxkw branch April 25, 2024 16:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation: user guide files in galleries/users_explain or doc/users
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants