General question about Python design goals

Steve Holden steve at holdenweb.com
Thu Dec 1 07:21:11 EST 2005


Christoph Zwerschke 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.
> 
Why? Why does it make sense to ask whether an RGB color has a particular 
value for one of red, green or blue? Why does it make sense to ask how 
many elements there are in an RGB color? It doesn't, so you must be 
talking about (ordered) *collections* of such items.

If you want a list of RGB colors then use a list. If you want a list of 
points in space then use a list. Why is a tuple preferable? [If the 
answer is "because a tuple can't be changed" go to the bottom of the class].

> 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 is a pretty bogus use case. Seems to me like a special case it's 
not worth breaking the rules for!

> 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.
> 
Bearing in mind the (likely) performance impact of using these items as 
dict keys don't you think some other representation would be preferable?

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC                     www.holdenweb.com
PyCon TX 2006                  www.python.org/pycon/




More information about the Python-list mailing list