Positional/keyword-only arguments #17

New Issue

lriesebos · 2021-06-14T18:39:21+08:00

lriesebos commented

2021-06-14 18:39:21 +08:00

Python allows keyword-only arguments and positional-only arguments. Will the compiler also deal with these constructs? This is not an urgent feature for us, but just wondering.

Python allows [keyword-only arguments](https://www.python.org/dev/peps/pep-3102/) and [positional-only arguments](https://www.python.org/dev/peps/pep-0570/). Will the compiler also deal with these constructs? This is not an urgent feature for us, but just wondering.

pca006132 commented

2021-06-15 09:32:33 +08:00

I don't think we would support this as we have no plan to support varargs.

pca006132 commented

2021-06-15 09:33:01 +08:00

Close this first unless someone wants further discussion about this...

pca006132 closed this issue

2021-06-15 09:33:01 +08:00

sb10q commented

2021-06-15 09:34:59 +08:00

Why not? This seems easy enough to do (assuming the RustPython parser supports it), and it does not depend on varargs.

sb10q reopened this issue

2021-06-15 09:34:59 +08:00

pca006132 commented

2021-06-15 09:36:43 +08:00

Why not? This seems easy enough to do (assuming the RustPython parser supports it), and it does not depend on varargs.

Sorry forgot to check it carefully, it seems that keyword-only arguments require varargs support as they are placed after varargs, but positional-only arguments do not require varargs, right?

> Why not? This seems easy enough to do (assuming the RustPython parser supports it), and it does not depend on varargs. Sorry forgot to check it carefully, it seems that keyword-only arguments require varargs support as they are placed after varargs, but positional-only arguments do not require varargs, right?

sb10q commented

2021-06-15 09:38:00 +08:00

keyword-only arguments require varargs support as they are placed after varargs,

No.

>>> def foo(a, *, b):
...   print(a, b)
... 
>>> foo(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() missing 1 required keyword-only argument: 'b'
>>> foo(1, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() takes 1 positional argument but 2 were given
>>> foo(1, b=2)
1 2

but positional-only arguments do not require varargs, right?

Correct.

> keyword-only arguments require varargs support as they are placed after varargs, No. ```text >>> def foo(a, *, b): ... print(a, b) ... >>> foo(1) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: foo() missing 1 required keyword-only argument: 'b' >>> foo(1, 2) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: foo() takes 1 positional argument but 2 were given >>> foo(1, b=2) 1 2 ``` > but positional-only arguments do not require varargs, right? Correct.

pca006132 commented

2021-06-15 09:40:47 +08:00

OK we can support it, but in the end we would just convert them into normal function calls, and we would treat them as position-only for function pointers (I don't want keywords to leak into the type signature). Is this OK?

sb10q commented

2021-06-15 09:42:48 +08:00

What's the problem with keywords into the type signature?
I would rather not support special arguments at all if the behavior with function pointers is inconsistent. Alternatively, we can also not support function pointers as long as we can do things like iterate on a list of objects and call a method on each (as discussed previously).

What's the problem with keywords into the type signature? I would rather not support special arguments at all if the behavior with function pointers is inconsistent. Alternatively, we can also not support function pointers as long as we can do things like iterate on a list of objects and call a method on each (as discussed previously).

pca006132 commented

2021-06-15 09:52:17 +08:00

What's the problem with keywords into the type signature?

This way, basically each function would be of its own type due to differences in parameter naming. Supporting this would not be hard, but it is weird when combined with function pointers.

Alternatively, we can also not support function pointers as long as we can do things like iterate on a list of objects and call a method on each (as discussed previously).

We can already do this by using tuples. I do think function pointer would be useful, e.g. lambdas, and it is easier to use function pointers than to wrap the function into a class with a method that only contains 1 function call...

> What's the problem with keywords into the type signature? This way, basically each function would be of its own type due to differences in parameter naming. Supporting this would not be hard, but it is weird when combined with function pointers. > Alternatively, we can also not support function pointers as long as we can do things like iterate on a list of objects and call a method on each (as discussed previously). We can already do this by using tuples. I do think function pointer would be useful, e.g. lambdas, and it is easier to use function pointers than to wrap the function into a class with a method that only contains 1 function call...

lriesebos commented

2021-06-15 23:32:45 +08:00

Yes as mentioned, this is not about varargs. This feature is not critical and I neither have strong opinions about the implementation if implemented. I think it would just be nice if the syntax would be accepted if it is not too much work.

Sign in to join this conversation.

No Label

No Milestone

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/nac3-spec#17