Tuples -- who needs 'em

[Bob Alexander]

"Fredrik Lundh" <effbot at telia.com> wrote:

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

Thanks for the pointer, but I'd already seen it. My post was not about lack
of understanding of tuples, it was simply intended to provoke some
interesting discussion. I realize tuples are probably a religious issue in
the Python community, so please don't take it the wrong way.

Let me repeat that I really like Python, I've written a lot of code with it,
I don't have any trouble understanding the concept of tuples vs. lists, and
I use both constructs at appropriate times. But I'm exploring the idea that
programming life might actually be somewhat better with lists and tuples
unified to a single datatype. Then there would be no need for FAQ # 6.15 :-)

I'm aware that this issue is not some great flash of insight. It is so
obvious that the Python in-group certainly have given it plenty of thought.
But that doesn't mean it's not worth talking about,

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

(Cool expression -- did you make that up?)

I completely agree, but several very good computer languages are
existence-proofs that lack of immutable lists is not "simpler than
possible".

> -- from a human perspective, using different syntax for
>    different things is good.

I agree with this, too (noting Lisp as possibly the worst example --
although a fine language with clear favorable influences on Python). But
my issue is not about syntax.

However, too bad about that nasty syntax irregularity that using parens for
tuples presents  (1,)  (Couldn't resist  ;-)

>    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.

Well, this is a half-empty vs. half-full thing -- I view them as pretty
similar. As a programmer I can choose to not modify a list and voila, it's
basically a tuple. It's not really necessary to have the language enforce
this (although it can be helpful in a large project).

BTW, both tuples and lists are ordered collections of non-homogeneous values
(i.e. the elements can be if different types).

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

This is the most compelling justification I've seen so far.

> -- 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.

Yet the concept of array is pretty fundamental to programming. Arrays are
usually thought of as mutable. Anyone having trouble with that concept is
pre-beginner  :-)

Without tuples, there would be no need to explain to
beginners the difference between tuples and lists. The fact that this is a
recurring topic on this list says something about that.

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

No.

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

Yes -- there is a proper balance for everything. I've happily used languages
that don't have immutable lists, though, and was
never aware that they were lacking something.

By the way, if immutable lists are necessary, why are immutable dictionaries
not necessary? Seems that all the same arguments would apply.

> -- 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...)

I'm sure tuples are not an acciental feature. And my issue comes from
understanding, not lack of understanding. I harbor a suspicion that the
motivation for tuples might have been more for implementation concerns
than for users' convenience. More on this below.

> > Suppose Python had only one sequence data type: list, and that we could
> use
> > 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
> tuple
> > 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?

Well, okay, I don't do it all the time, and it's not a big deal. I'm just
exploring the opportunity for a small reduction in the "cognitive load" of
Python programming. In my opinion, it's the difference in cognitive load
that mainly differentiates ease of programming in languages like Python from
languages like C++. Thankfully we don't have to decide among 10 or so
different collection types. But even small choices to make when choices are
not necessary cause the mind to leave the problem that is being solved to
deal with a programming "bookkeeping" issue.

> > 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?

I wish there was something like the C++ ARM for Python, where choices in
language design are discussed and justified. I don't particularly like C++,
but I like that book because of the insight it provides. If there is such a
book or paper on Python, I'd appreciate a pointer to it.

There is a design pattern (that is not in the book!) where some program
features exist more for for benefit of the program implementor(s) than for
the program user(s). Is there some element of this in the existence of
tuples as a source language construct? I'm aware the the feature has been
well-sold as a benefit to programmers.

My suspicion (lacking any real knowledge about this, and with deepest
respect for the designer(s) of Python) is that there was
already a need for an internal "tuple" datatype in the language's
implementation, and it was efficient for
things like function argument frames, and maybe for
multiple function return values, etc. Given that, maybe apply() could be
implemented
 more efficiently if tuples were exposed at the source language level and
the
user passed tuples to apply(). (Note that apply() will convert sequences to
tuples if they are not already, thus efficient use of apply requires that
tuples be passed, not lists.) Given this sort of justfication for tuples,
many more
reasons were then noticed why tuples are a Good Thing.

I'm all for efficient implementation, but Python usually opts for
programming ease over raw efficiency. I agree with that philosophy -- design
for ease of use and eventually techniques will be figured out for
making the underlying implementation more efficient.

-- Bob