Tim Golden wrote: > Christoph Zwerschke wrote: >> And can somebody explain what is exactly meant with >> "homogenous data"? > > This seems to have been explained a few times > recently :) Basically, if you have a "list of xs" > and remove one item from it, it is still a "list of xs",
According to that definition, everything would be homogenous. I guess what you wanted to say is if you have an "x" and remove one item from it it is still an "x", then it's homogenous. The problem is that depending on how exactly you define "x", you will come to different results. > 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. > 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. >> Concretely speaking, which data type should I use >> for coordinate tuples? Usually, tuples are used. Does this mean that I >> should better use lists from now on because all the components have the >> same type? > > This would seem to be slightly false logic (and very > possibly used tongue-in-cheek). Heterogeneous data > doesn't mean that each item *has* to be different, merely > that they *may* be. I don't think it's a problem of false logic but the problem that "homogenous data" is not defined. We probably agree that it usually makes perfect sense to use tuples for coordinates. But in certain mathematical algorithms it also makes sense to ask for the number of zero components of a coordinate tuple - the count() method would be helpful here. 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". -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
