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:
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
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:
With this, users can call this in a few different formats:
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: