-
Notifications
You must be signed in to change notification settings - Fork 608
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
refactor(api): differentiate between positional and keyword arguments in most APIs #10734
refactor(api): differentiate between positional and keyword arguments in most APIs #10734
Conversation
Once this gets reviewed, I will give the individual commits a |
a0c329c
to
2dbc41c
Compare
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.
Before I go through the rest of these -- I thought I should check and make sure I'm not missing something -- do we not want to standardize the read_*
methods with forced positional and keyword args?
I think ultimately we do, which is why I ended up grinding some of them out earlier this morning. |
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.
CI failures notwithstanding, this looks good to me. There's some question remaining about whether we always, e.g. say path
as the arg name to read_*
functions regardless of whether it takes a list of paths, or if we want the distinction. But we don't have to handle that here, since making it positional-only means we can change it without breaking anyone.
b53a5a3
to
aefebb3
Compare
f89b525
to
af56ef3
Compare
…w_by`/`Table.alias` argument positional-only
5dae4bc
to
ae33e9d
Compare
Closes #9125.