Greg Wilson is suggesting things Python 3000 could leave out and suggests tuples.
In the comments, Phillip Eby holds him to task for the assumption that tuples are just constant lists:
Tuples are not constant lists -- this is a common misconception. Lists are intended to be homogeneous sequences, while tuples are hetereogeneous data structures.
I think it was years into my use of Python that I realised this and stopped thinking about them as just constant lists. It was a powerful revelation for me.
So while I agree with Greg that many (most?) programmers don't understand the distinction, I think they are missing out and that we'd be better off improving the way lists and tuples are documented than try to conflate what is, in my opinion, a very useful distinction.
One way I'd express it (in addition to Phillip's quote above) is that the index in a tuple has an implied semantic. The point of a tuple is that the i-th slot means something specific. In other words, it's a index-based (rather than name based) datastructure.
This notion of 'tuple' is very important in relational algebra (as Phillip also points out) and so I've been thinking about it in the context of relational python too.
When I started playing around with relational python (which I need to get back to blogging about), it occurred to me that it might be useful to have the notion of a tuple whose slots could additionally be named and then accessed via name. I implemented it that way in Basic Class for Relations.
UPDATE (2011-11-22): of course, the idea mentioned in that last paragraph is now a reality in the form of Python's namedtuple.
The original post was in the categories: python relational_python but I'm still in the process of migrating categories over.
The original post had 35 comments I'm in the process of migrating over.