There is no such mechanism. Functions either have no argument or
they have one argument. The syntax for one argument allows a
comma-separated list of expressions, which builds a tuple; it is this
tuple value that becomes the *single* argument to the function. When
the function is actually declared with multiple arguments, it expects
a tuple and unpacks this into the respective arguments, just like an
unpacking assignment.
>This brings up the issue of
>ambiguous situations. What if function f takes three arguments, a, b, c,
>and is given two arguments (1, 2) and (3, 4)? Do a and b get 1 and 2
>leaving c with (3, 4), or does a get (1, 2) while b and c get 3 and 4?
>Whichever way it works, what if the user wants to do it the other way?
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".
(This is Daniel:)
> >f(x) as compared with f(1, 2, 3) really does
> >a different thing internally, and it was confusing to me as a
> >new user to discover that these were intended to have the same result.
(my reply:)
> Erm, I don't understand what you mean by "really does a different
> thing internally".
(Daniel again:)
>Well, the user is supposed to not be concerned about whether separate
>arguments are required, and so the two calls are semantically equivalent
>since they result in the same thing, but to do the "same thing" in each
>case, they have to do different things internally.
I still maintain nothing is done differently. Maybe my explanation
above (1-or-1 argumet) explains your confusion?
>Alternatively, the function could be declared f((x, y)). Analogously, the
>assignment above should be done like (x, y) = p. ML and probably
>other languages have this kind of pattern-matching/argument-parsing
>mechanism developed to a fine art.
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))): ...
and call it in either of the following ways:
f(a, (b, c, d), (e, (f, g)))
bcd = b, c, d
fg = f, g
f(a, bcd, (e, fg))
efg = e, fg
f(a, bcd, efg)
abcdefg = a, bcd, efg
f(abcdefg)
(But I admit I don't know even a little bit of ML.)
>How about if x is a function object, then x[y] does a function call
>with list [y] as argument. Or if x is a list or table, then x[y] does the
>subscription with index/key y.
I have the feeling that this is something which should be unambigous
at compile time (at least in a computer language -- in natural
languages this kind of things happens all the time). [If you still
disagree I'm willing to go into an argument off-line; I have a feeling
this is different from using '+' for strings and numbers, but it takes
too long to explain why I think that is so.]
--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"I'm sorry, is this a five-minute argument, or the full half-hour?"