In article <[EMAIL PROTECTED]>, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
> Donn Cave <[EMAIL PROTECTED]> writes: > > If t is a valid argument tuple for function f, then can t[1:] > > also be a valid argument tuple for function f? > > > > For ordinary functions without special argument handling, no. > > We know that without having to know anything about t, and not > > much about f. This is characteristic of tuple applications. > > I'm not sure what you're saying. The current situation is if I say > > def f(*args): > print args > > f (1,2,3,4,5,6,7) > > f receives a 7-element tuple, but if I say > > f (8, 9, 10) > > f receives a 3-element tuple. OK, and of course - f has some implementation which assigns meaning to each parameter, according to its position. - it does this by assigning names to those positions (this isn't essential to my point, but reinforces the struct analogy) For any basic, no-tricks implementation of f, the second application is going to have problems: - fourth and following positions have no actual parameters - if you meant to portray (8, 9, 10) as t[4:], where t is (_, _, _, _, 8, 9, 10), following my proposition above, then it should be clear that inasmuch as t[4] for example has some meaning in terms of f, one cannot preserve this meaning in a smaller slice of t. Please think about it, because I do not intend to try to explain this again. So the parameters of f form a sort of type -- an ordered sequence of values, where each item has a different meaning according to its absolute position in the sequence, and where a name is assigned (by at least f and optionally by its caller) to each position. This type can be represented by many possible values, but we can observe that just as a matter of principle, for any value of this type, a smaller slice is not also of this type. Of course the word "type" above is about something that is not formally implemented in Python, so you can obtusely quibble about whether it's a type or not, but the constraints are real. > I'm asking whether f should receive a list instead. I think that is > more in keeping with the notion of a tuple being like a structure > datatype. How can there be a structure datatype with an unpredictable > number of members? Unpredictable? How do you manage to write functions in this case? Are all your formal parameter lists like (*a), with logic to deal with the variable lengths? But even that wouldn't by itself make your point. Any experienced C programmer is likely to have "subtyped" a struct, adding one or more values to the end of the parent struct, so the value can be passed to functions that expect the parent type. Variable length isn't strictly foreign to struct types. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
