There is no such mechanism.
I was referring (without the explicit reference) to someone else's suggestion
to consider optional and rest args. I rather like them too, and adding
them to current Python might be a problem.
> [calling function of two arguments with 3 arguments...]
There is no ambiguity. This is a run-time error (detected in the
called function), similar in nature to the error in assignments like
"a, b = 1, 2, 3".
So in this situation, one is required to put the explicit parens in
(i.e. f((1, 2), 3)), but as a special case, you don't want to require
explicit parens in f(1, 2) when passed to a function declared f(p).
I can appreciate the motivation for this, but the inconsistency bothers
me more.
>Alternatively, the function could be declared f((x, y)).
Isn't Python's mechanism very similar (although probably implemented
totally different), except that extra parentheses don't count? After
all, you can define a function as follows
def f(a, (b, c, d), (e, (f, g))): ...
Oh, well I guess I forgot that Python can do this (can you tell I
am not an active user?). In that case, I don't see any point in making
parens optional at the top level of an argument list, except for the
small convenience it affords sometimes. Look at it this way: if the
user is grouping things in a tuple, the elements should have more
relationship to one another than just the fact that they will be passed
as a collective argument to a function. And if doing away with this
"problem" leads to a better solution to the no argument/one argument
problem, I am all in favor of this code breaking change to Python syntax.
dan