>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.
Erm, I don't understand what you mean by "really does a different
thing internally".
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.
Using your proposal (if I understand it well), I would
have to write f(p[0], p[1]) if it was declared as f(x, y), or I would
have to call it as f((x, y)) if it was declared as f(p). Currently,
in Python, there is an informal rule that says "placing extra
parentheses never hurts".
I don't think calling f((x, y)) would be as annoying as f(p[0], p[1]),
so people would tend to declare the function with f(p) if it is meaningful
to collect x and y into one argument, and then if the function writer
wanted to break out the parts of p, the assignment x, y = p does the job.
Perhaps the same ambiguity I mentioned above exists in assignments..?
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.
*** Question to the general audience: is this serious enough to
warrant changing the language (and potentially lots of existing code)?
I think you need to think more about the ambiguous cases as well as user
confusion.
>Maybe you want to consider calling f with arguments being the elements
>of the tuple x using the syntax "f x". Then "f (1, 2, 3)" is really
>the same kind of function call as "f x".
This was used in ABC, but it would be inconsistent in Python (assuming
no other syntax changes). For example, it would render x[y] ambiguous:
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. You couldn't tell until run time which
it would be since the type of x is not declared, but the ambiguity would
be resolved.
Also, function calls without arguments would be impossible
Yes this is still a problem. I prefer the ML-like pattern matching in
any case.
Dan LaLiberte
National Center for Supercomputing Applications
liberte@ncsa.uiuc.edu
(Join the League for Programming Freedom: league@prep.ai.mit.edu)