Skip to content
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: standardize use of keyword/positional-only arguments #9125

Open
Tracked by #8996
jcrist opened this issue May 6, 2024 · 0 comments
Open
Tracked by #8996

refactor: standardize use of keyword/positional-only arguments #9125

jcrist opened this issue May 6, 2024 · 0 comments
Labels
breaking change Changes that introduce an API break at any level refactor Issues or PRs related to refactoring the codebase

Comments

@jcrist
Copy link
Member

jcrist commented May 6, 2024

Python 3.8+ supports both keyword-only and positional-only arguments. We might want to survey our existing APIs and try to consistently make use of positional and keyword-only arguments in cases where they make sense.

They main way this would show up as an improvement is making it easier for us to refactor internals without making things a (potentially) breaking change for users. Say we had an existing function:

def my_excellent_function(arg1, arg2=None, arg3=None):
   ...

With this, users can call this in a few different formats:

my_excellent_function(1)  # positional with defaults
my_excellent_function(1, 2, 3)  # all as positionals
my_excellent_function(arg1=1, arg2=2, arg3=3)  # all as keywords
my_excellent_function(1, 2, arg3=3)  # mix of positional and keyword

Allowing these different calling conventions makes amending this API trickier. We have to worry about adding new keyword arguments only at the end, and never renaming any of the positional arguments (since the user may have called them by name). Moving to a stricter positional-only/keyword-only subset would mean that:

  • We can change the names of positional arguments later without worrying that users may have passed them by keyword
  • We can reorder keyword arguments without worrying that users may have have passed them positionally
@jcrist jcrist added refactor Issues or PRs related to refactoring the codebase breaking change Changes that introduce an API break at any level labels May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Changes that introduce an API break at any level refactor Issues or PRs related to refactoring the codebase
Projects
Status: backlog
Development

No branches or pull requests

1 participant