Does the Standard Mandate Position-Only and Keyword-Only Arguments?

[djl11]

I've noticed that positional-only and keyword-only arguments are used in the standard. However, as far as I can tell, the unit tests do not assert that failures occur if these positional or keyword arguments are called incorrectly.

For example, Ivy's ceil implementation can be called like so:

ivy.ceil(x=my_array)

without raising an error, which should not be permitted by the standard. However, the Array API unit tests are still passing.

We have opted to remove position-only and keyword-only arguments to reduce user restrictions, but we could pivot on this decision.

I'm curious, will you treat frameworks which remove all *,\ from the function signatures as still adhering to the standard? If not, will the unit tests change to include such assertions in future?

[rgommers]

Hi @djl11, thanks for the question.

I'm curious, will you treat frameworks which remove all *,\ from the function signatures as still adhering to the standard?

Good question. All implementations may, and are likely to, offer additional functionality beyond what's in the standard. That does not break compliance with the standard. However, if the users is using those extensions then of course their code may no longer be portable.

To give an example, staying with ceil:

• standard gives the signature ceil(x: array, /). User can therefore write, for an input x, only one form: ceil(x).
• If Ivy removes / then a user can write two forms: ceil(x) and ceil(x=x). The latter is both not guaranteed to be portable and less idiomatic (it just looks odd).

We've attempted to strike a balance; when there are two reasonable spellings then we don't enforce positional/keyword-only, when there's clearly one preferred way to spell something then we added it.

If not, will the unit tests change to include such assertions in future?

I'd say it's certainly not a priority and if it is added then it should be well separated from other tests, because many libraries will not be adding / and * consistently (at least at first) because historically they haven't been used much - they're relatively new Python features after all.

@asmeurer or @honno may be able to say more about testing.

[honno]

Yep the "primary" tests in the suite only assume pos-only and kw-only args, which will work just fine for normal args and kwargs—we don't explicitly test for them. As Ralf says it's probably not too interesting the test, given from an end-user perspective the lack of pos/kw-only restrictions should not effect interop between adopting array libraries... other than a developer of an array-consuming library (e.g. SciPy, scikit-learn) accidentally assuming normal args due to an array-generating library's (e.g. NumPy, PyTorch) lack of pos/kw-only adoption.

Testing for them in our primary tests would be seemingly counter-productive, as those signature errors could prevent/minimise testing the things we care much more about (i.e. broadcasting/type-promotion/logic). We do have test_signatures.py, but that doesn't explicitly test pos/kw-only args either—those tests are before my time, but I guess for the same reason that a lack of pos/kw-only restrictions doesn't really effect interop.

[djl11]

Thanks @rgommers @honno for taking the time with your detailed replies, both incredibly helpful. Yes this all makes total sense, and this is a great point regarding the lack of portability if positional-only and keyword-only args are excluded from the methods. We will keep pondering our decision to exclude them in Ivy; perhaps we will adopt these as requirements too. Thanks again!