One of the reasons I love Python is the expressive power / reduced programming effort provided by tuples, lists, sets and dictionaries. Once you understand list comprehensions and a few of the basic patterns using in and for, life gets so much better! Python rocks.
However I do wonder why these constructs are treated as differently as they are, and how this is changing (getting stranger) over time. Back in Python 2.x, I could’ve made an argument they were all just variations of a basic collection type, and that it was kind of irritating that some non-exotic use cases require you to convert a dictionary to a list and back again. (Isn’t a dictionary just a list of tuples with a particular uniqueness constraint? Isn’t a list just a set with a different kind of uniqueness constraint?).
Now in the 3.x world, it’s gotten more complicated. There are now named tuples — starting to feel more like a special-case dictionary. There are now ordered dictionaries — starting to feel more like a list. And I just saw a recipe for ordered sets. I can picture this going on and on … what about unique lists, etc.
The Zen of Python says “There should be one– and preferably only one –obvious way to do it”. It seems to me this profusion of specialized collections types is in conflict with this Python precept.
What do the hardcore Pythonistas think?
These data types all serve different purposes, and in an ideal world you might be able to unify them more. However, in the real world we need to have efficient implementations of the basic collections, and e.g. ordering adds a runtime penalty.
The named tuples mainly serve to make the interface of stat() and the like more usable, and also can be nice when dealing with SQL row sets.
The big unification you’re looking for is actually there, in the form of the different access protocols (getitem, getattr, iter, …), which these types mix and match for their intended purposes.