Dynamic API: Support positional-only arguments #4660
Labels
acknowledge
To be acknowledged in release notes
beta 1
effort: small
enhancement
pr
Pull request exists
priority: medium
Milestone
Comments
|
If someone is interested to contribute, the parsers for different arguments are here: |
pekkaklarck
pushed a commit
that referenced
this issue
Apr 3, 2023
pekkaklarck
added a commit
that referenced
this issue
Apr 3, 2023
Make, for example, `['*', 'kwo', '/', '???']` and `['**kws', '/']` explicitly invalid. Part of #4660.
pekkaklarck
added a commit
that referenced
this issue
Apr 3, 2023
1. Remove new "Positional only argument syntax with dynamic libraries" section added as part of #4660. It mostly explains how positional arguments work in general, but that's alrady explained elsewhere. We can consider adding adding it back so that it explains how they work with the dynamic API, but I'm not sure it's needed. We don't have such a section with `*varargs` either and believe the remaining documentation and examples explain this topic well enough. 2. Enhance formatting of examples related to argument specs returned by `get_keyword_arguments`. 3. Make names of tests in examples more clear. Most importantly, avoid "Positional only" term when not actually talking about positional-only arguments.
pekkaklarck
pushed a commit
that referenced
this issue
Apr 4, 2023
pekkaklarck
added a commit
that referenced
this issue
Apr 4, 2023
Make, for example, `['*', 'kwo', '/', '???']` and `['**kws', '/']` explicitly invalid. Part of #4660.
pekkaklarck
added a commit
that referenced
this issue
Apr 4, 2023
1. Remove new "Positional only argument syntax with dynamic libraries" section added as part of #4660. It mostly explains how positional arguments work in general, but that's alrady explained elsewhere. We can consider adding adding it back so that it explains how they work with the dynamic API, but I'm not sure it's needed. We don't have such a section with `*varargs` either and believe the remaining documentation and examples explain this topic well enough. 2. Enhance formatting of examples related to argument specs returned by `get_keyword_arguments`. 3. Make names of tests in examples more clear. Most importantly, avoid "Positional only" term when not actually talking about positional-only arguments.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
RF 4.0 added support for Python's positional-only arguments (#3695). It isn't that important feature, but sometimes it comes handy. For consistency reasons also dynamic libraries should support it.
Implementing this enhancement shouldn't be too complicated. Our
ArgumentSpecalready supports positional-arguments and that's what is used during execution. The only needed change ought to be enhancing the code that parses argument information returned by dynamic libraries. Well, even before that we needed to agree on the syntax but['posonly', '/', 'normal']that matches the syntax used by Python is a pretty obvious candidate. It's also consistent how the dynamic API supports named-only arguments like['normal', '*', 'namedonly'].The text was updated successfully, but these errors were encountered: