On 12/15/06, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > > If you have a tuple containing, say, a 2d coordinate pair, > > and remove something from it, it's no longer a coordinate pair. > > Now here comes the ambiguity. If you interpret "x" as "coordinate tuple" > it would be still one (a 1-tuple), but if you interpret "x" as > "coordinate pair" then it would indeed not be an "x" any more. So that > definition is not really helpful.
But the new 1-tuple is no longer usable in the same contexts as the coordinate pair. In the coordinate pair, you can infer the item's meaning from its position. > > A typical example of their combined use is a set of > > rows returned from a database: each row is a tuple > > of fields, the same as all other such rows, and removing > > or adding a field would make no sense. However, add > > a new row to the list and it remains a list of rows. > > Sounds plausible. But when I read a row with the name and forename of a > person, I might want to collapse the name and forename into one element > before I hand it over to a function that will display it as a table. Or > I may want to delete certain elements which are not important. In such > cases, having each row as list may also make sense. Sure, you can translate the tuple into a different tuple for a different purpose, but in terms of the database, only the original tuple (or other with the same structure) is meaningful. > The statement "if you are looking for index() or count() for your > tuples, you're using the wrong container type" is too extreme I think. I > would agree with "it *may indicate* that you should better use lists". Oh, absolutely, it's not a hard and fast rule. But I find that if I try to decide whether to use a tuple or a list based on lists for homogeneous collections and tuples for heterogeneous collections where position carries semantic meaning, then I end up using the type that does what I need. Homogeneous collections often need to be sorted or searched, wheras heterogeneous collections are often used as dictionary keys. -- Cheers, Simon B [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
