Tuples -- who needs 'em

Fredrik Lundh effbot at telia.com
Mon Apr 3 11:56:11 EDT 2000

Bob Alexander wrote:
> This is not an [intentional] flame bait, nor an April Fool's message, but
> think about it: Python has two "sequence" data types, lists and tuples,
> which from the Python programmer's perspective are only slightly
> How does having both types significantly improve life for Python
> programmers?

some random remarks (please consider them all before

-- http://www.python.org/doc/FAQ.html#6.15

-- things should be as simple as possible, but no simpler.

-- from a human perspective, using different syntax for
   different things is good.   tuples are simple structures.
   lists are collections of homogenous (in one sense or
   another) values.  from a program design perspective,
   that are two radically different things.

-- adding a comment won't make an object immutable.

-- tuples can be used as dictionary keys.  mutable
   collections can not.

-- python's core types fall into two categories: the first
   is simple types, like numbers, strings, and tuples. they
   are all immutable.

   the other category is container (or collection) objects.
   they're far more powerful, and harder to use for beginners.

-- this has been discussed over and over again.  have you
   studied earlier threads on this topic?

-- good designers know that hypergeneralization tends to be
   a bad idea.

-- what would happen if we took them away?

-- do we really need yet another "I don't fully understand this,
   so it should go away" thread?  do you really think that tuples
   are just an accidental feature?  (just asking...)

> Suppose Python had only one sequence data type: list, and that we could
> it in all places where tuples are needed now. I would never have to think
> about whether to use tuple or list. I would never have to convert from
> to list or vice versa. Just one more thing I don't have to bother with.

if you find that you end up doing this all the time, you're not
following the "fixed structures vs. homogenous collections"
design rule.

(or you're using extension modules that haven't been upgraded
to use the abstract sequence API.  most standard extensions do,
these days).

if you don't do this all the time, what's the big deal?

> I suspect there will be several answers offered as to why we need both
> types, but I also suspect most of the benefits are for the Python
> implementor(s), not programmers.

umm.  I thought having two similar types meant more work for
the python implementors, not less?


More information about the Python-list mailing list