question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

API: keywords only arguments

See original GitHub issue

Is your feature request related to a problem? Please describe.

Keywords only arguments are arguably clearer and allow easier refactoring on our side. When adding a new feature, we are already thinking about using * to declare keyword only arguments.

Describe the solution you’d like.

scikit-learn already went through this process and with their v1 coming up, the whole code base is already keywords-only arguments. Hence, if accepted, I propose we follow the same path.

They did it in two phases:

  1. Deprecation phase with a wrapper: it takes a function and look at which arguments are keywords only. If you call the function using a positional argument instead of a keyword only argument (if f(a, *, b) and you do f(1, 2) instead of f(1, b=2)) then it will raise a deprecation warning. The function will still be working as the keyword arguments would not be enforced yet. The wrapper will convert the positional argument into a keyword argument.
  2. Remove the wrapper: after the deprecation cycle, remove the wrapper and we are done.

xref https://github.com/scikit-learn/scikit-learn/issues/15005

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:25 (25 by maintainers)

github_iconTop GitHub Comments

2reactions
rgommerscommented, Sep 14, 2021

+1 for using in new code, keyword-only args are very helpful.

For existing code, I don’t think we can do it for the whole code base - too painful. We could look at it for a specific submodule if there’s a good reason for it I think (for example, we want to add more keyword arguments and the order of arguments is becoming quite odd).

1reaction
h-vetinaricommented, Mar 28, 2022

OK cool. The scikit helper is also much prettier than the one I hacked together.

I think it would be good idea to have something of a standing policy that if we’re touching the signature of a function in a way that needs a deprecation cycle (e.g. remove/rename a keyword) to also use that to turn the keywords into keyword-only arguments, but for now I’ll just try to remember that when I come across a case.

Read more comments on GitHub >

github_iconTop Results From Across the Web

PEP 3102 – Keyword-Only Arguments
This PEP proposes a change to the way that function arguments are assigned to named parameter slots. In particular, it enables the declaration...
Read more >
Positional-Only Arguments - Real Python
You can specify that you want keyword-only arguments by using an asterisk ( * ). 04:31 Any arguments after that * must be...
Read more >
SLEP009: Keyword-only arguments
This proposal discusses the path to gradually forcing users to pass arguments, or most of them, as keyword arguments only.
Read more >
Explain Keyword-Only Arguments (VarArgs) in Python
Python 3.x introduces more intuitive keyword-only arguments with PEP-3102 (keyword arguments after varargs can only be bound by name).
Read more >
Python keyword only arguments - getKT
It improves the readability · API functions can accept the critical parameters as keyword only arguments to avoid ambiguity · You can create...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found