On 12/1/05, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > I think this all boils down to the following: > > * In their most frequent use case where tuples are used as lightweight > data structures keeping together heterogenous values (values with > different types or meanings), index() and count() do not make much sense. > > I completely agree that his is the most frequent case. Still there are > cases where tuples are used to keep homogenous values together (for > instance, RGB values, points in space, rows of a matrix). In these cases > it would be principally useful to have index() and count() methods. > > But: > > * Very frequently you will use only 2- or 3-tuples, where direct queries > may be faster than item() and count(). (That's probably why Antoon's RGB > example was rejected as use case though it was principally a good one). > > * Very frequently you want to perform operations on these objects and > change their elements, so you would use lists instead of tuples anyway. > See my use case where you would determine whether a vector is zero by > count()ing its zero entries or the rank of a matrix by count()ing zero rows. > > * You will use item() and count() in situations where you are dealing > with a small discrete range of values in your collection. Often you will > use strings instead of tuples in these cases, if you don't need to sum() > the items, for instance. > > So, indeed, very few use cases will remain if you filter throught the > above. But this does not mean that they do not exist. And "special cases > aren't special enough to break the rules." It should be easy to imagine > use cases now. > > Take for example, a chess game. You are storing the pieces in a > 64-tuple, where every piece has an integer value corresponding to its > value in the game (white positive, black negative). You can approximate > the value of a position by building the sum(). You want to use the tuple > as a key for a dictionary of stored board constellations (e.g. an > opening dictionary), therefore you don't use a list. >
This really looks to me like you have your priorities inverted. Practically everything you want to do with this structure is list-like, so why not make it a list and convert it to a tuple when you need to use it as an index? Even better, since you're doing a lot of list operations, why not make it a list and define unique IDs or something to use as indices? A minor change in your design/thinking (not trying to use a tuple as a frozen list) instead of a change in the language (making tuples more like frozen lists) seems to be the warranted solution. But maybe thats just me. > Now you want to find the field where the king is standing. Very easy > with the index() method. Or you want to find the number of pawns on the > board. Here you could use the count() method. > > -- Christoph > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list