-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Use more kwonly arguments, less manual kwargs-popping. #15680
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
Conversation
6ada6c4
to
3353e74
Compare
grid_helper = self.get_grid_helper() | ||
if not hasattr(grid_helper, "get_boundary"): | ||
raise ValueError("grid_helper must implement get_boundary method") |
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.
Is it really helpful to move this into a private method? Seems clearer for a user if the exception comes from the class init directly.
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.
_gen_axes_patch is called immediately at init so users would see the message immediately, just with a few more stack frames. Putting the check e.g. after the super()init call would actually be useless because super()init would already have called _gen_axes_patch and thus already errored out.
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.
I don't understand. The first thing the original code did in __init__
was validating the grid_helper
parameter.
1964586
to
fa7b508
Compare
For indicate_inset, I fixed the doc issue by adding a property table to the docstring. For inset_axes that's not possible because at the time the method is defined, the Axes class doesn't actually exist yet so has no entry in the interpd map. I'm not sure it's really worth fighting the docstring interpolation system to fix that and I'm not sure I can write a meaningful doc for that parameter ( |
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.
I'd prefer reverting the changes to the label
parameter. AFAICS this is not intended as a user-facing parameter and thus should better not appear in the signature.
grid_helper = self.get_grid_helper() | ||
if not hasattr(grid_helper, "get_boundary"): | ||
raise ValueError("grid_helper must implement get_boundary method") |
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.
I don't understand. The first thing the original code did in __init__
was validating the grid_helper
parameter.
Re: label: reverted, put in a small variation on the handling. |
This is not fundamentally different from other parameter checks. The checks are in place so that we can error out from a place close to the user call with a descriptive error message. |
The error message is just as descriptive, and will be triggered in the init call (or more specifically two frames below it, but the user will need to go up the traceback to check where their own incorrect code is anyways). Also, consider for example a (hypothetical) subclass of FloatingAxes for which the grid_helper would be pre-set to some default value -- making the grid_helper kwarg optional (or even not available). With the earlier design, one would additionally need to override init to undo the currently existing check. With this PR's design one doesn't need to do anything. Hence I would consider this PR's design more composable. |
I can anticipate that for "grid_helper must implement get_boundary method" but not for "FloatingAxes requires grid_helper argument".
Generally, if you change the signature of a function, it's reasonable that it should be reimplemented. Having parameters just A major problem with this part of the code is that it's very indirect and largely undocumented. I cannot judge the effect of changes and therefore I'm unable to review that part. If you're attached to the changes, would it be an option to move that part to another PR so that I an approve the rest of this PR and we hopefully find somebody else to review the floating axes stuff. |
I reverted that change (except for the docstring unduplication). |
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.
Modulo a minor comment.
rebased |
Doc failure:
|
oops, hopefully fixed... |
PR Summary
PR Checklist