-
Notifications
You must be signed in to change notification settings - Fork 52
Does standard prohibit inclusion of additional keyword-only arguments? #869
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
Comments
Extra optional positional arguments and keywords can always be added by an implementation, that is perfectly fine and every existing implementation except for
So those are both fine. |
Yup! I will submit a PR to add exactly that. This came up in mdhaber/marray#6 (comment). |
Would this be ok to make it explicit that the list is not comprehensive?
Or is that too flexible? |
That sounds perfectly fine to me. |
Code written against the strictest implementations of the standard should work. That means that additional optional keyword arguments are fine, because even though most code won't reference them, they will have default values. But additional required positional or keyword arguments are not OK, because those will require the code to be updated. So for example, if the standard defines def f(x, /, y=1):
... an implementation could define def f(x, /, y=1, z=2):
... but it would not be OK for an implementation to define def f(x, z, /, y=1):
... or def f(x, /, *, z, y=1):
... because code written against the standard like |
The "Conformance" section states:
This seems to leave a bit of gray area. For instance, can implementations of functions defined in the standard accept additional arguments not defined by the standard (as long as the default behavior complies with the standard)?
Let's take
numpy.asarray
as an example implementation ofasarray
.I know that the fact that the positional arguments are not positional-only is non-conformant: "When a function signature includes a /, positional parameters must be positional-only parameters." Likewise,
dtype
should be keyword only. That aside....Is NumPy's inclusion of an additional positional argument
order
considered non-conformant? How about the keyword-only argumentlike
?The text was updated successfully, but these errors were encountered: