Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
Makefunctions 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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
There was a problem hiding this 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 originallyplanned signature was `secondary_xaxis(location, forward=...,inverse=...)` where the keywords actually add some semantics (thoughthat signature overall seems worse); however, for a single `functions`parameter, having to type an extra `functions=` in the call doesn't helpthe reader much (either they know what secondary_x/yaxis does, in whichcase the explicit kwarg doesn't matter, or they don't, in which case thekwarg name hardly helps)... and is a bit annoying. See the modifiedgallery entry, for example.
oops, done. |
Is an API change note worthwhile? If not, anyone can merge. |
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 |
91234e2 intomatplotlib:mainUh oh!
There was an error while loading.Please reload this page.
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 singlefunctionsparameter, having to type an extrafunctions=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