Donn Cave schrieb: > As I'm sure everyone still reading has already heard, the natural usage > of a tuple is as a heterogenous sequence. I would like to explain this > using the concept of an "application type", by which I mean the set of > values that would be valid when applied to a particular context. For > example, os.spawnv() takes as one of its arguments a list of command > arguments, time.mktime() takes a tuple of time values. A homogeneous > sequence is one where a and a[x:y] (where x:y is not 0:-1) have > the same application type. A list of command arguments is clearly > homogeneous in this sense - any sequence of strings is a valid input, > so any slice of this sequence must also be valid. (Valid in the type > sense, obviously the value and thus the result must change.) A tuple > of time values, though, must have exactly 9 elements, so it's heterogeneous > in this sense, even though all the values are integer.
I understand what you want to say, but I would not use the terms "homogenuous" or "heterogenous" since their more obvious meaning is that all elements of a collection have the same type. What you are calling an "application type" is a range of values, and the characteristic you are describing is that the range of values is not left when you slice (or extend) an object. So what you are describing is simply a slicable/extendable application type. It is obvious that you would use lists for this purpose, and not tuples, I completely agree with you here. But this is just a consequence of the immutability of tuples which is their more fundamental characteristic. Let me give an example: Take all nxn matrices as your application type. That applicaiton type is clearly not slicable/extendable, because this would change the dimension, thus not "heterogenous" in your definition. So would you use tuples (of tuples) or lists (of lists) here? Usually you will use lists, because you want to be able to operate on the matrices and transform them in place. So you see the more fundamental characteristic and reason for prefering lists over tuples is mutability. Let us assume you want to calculate the mathematical rank of such a matrix. You would bring it in upper echelon shape (here, you are operating on the rows, thus you would use lists) and then you would count the all-zero rows. Ok, this is not an example for using count() on tuples, but it is an example for using count() on a "heterogenous" collection in your definition. I completely agree that you will need count() and item() much less frequently on tuples because of their immutability. This is obvious. (Tuples themselves are already used less frequently than lists for this reason.) But I still cannot see why you would *never* use it or why it would be bad style. And I don't understand why those who smile at my insistence on design principles of consistence - propagating practicability instead - are insisting themselves on some very philosophical and non-obvious design principles or characteristics of tuples. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list