Tuples -- who needs 'em

[Bob Alexander]

"Martijn Faassen" <m.faassen at vet.uu.nl> wrote:

> Except that you can suddenly do this:
>
> results = foo()
> ...
> results.append(5)
> ...
> first, second, third, fourth = results # error

True -- but there is a simple solution: omit the second statement  :-)
There are things you can do to sabotage things even with tuples; for example
replace "results.append(5)" with "results = (1,2)". Is mysterious changing
of lists a frequently-occurring problem?

> A tuple tends to contain a few heterogenous things,
> while a list tends to contain a larger number of homogenous things.

This distinction seems to be in the minds of several in this thread, but is
not mentioned in any Python doc I've seen, is not enforced by the language,
and, IMO, is unnecessary. In languages with mutable lists but no tuples,
lists are often used for spiritually-unmutable sequences of a few
hetrogenious things. I've never though of the syntactic distinction as
necessary or particularly helpful.

I think the "homogeniety" idea is a carryover from the many languages that
do not permit heterogeneous sequences. Homogeneous sequences should be used
where appropriate, but there are uses for heterogeneous sequences too.
Flexibility is good.

> Functional programming languages have the concept. At least the
> *spirit* that you shouldn't be changing a list. This is different from
Python,
> as we do change (homogenous) lists. The pattern in functional programming,
> which *does* occur often in Python code as well, is some operation over
> all elements of a list creating a new list (map(), though this is often
> expressed in Python as a 'for' loop, partially due to the nastiness of
> 'lambda'). The old list isn't changed.

As you say, the functional programming paradigm can be nicely expressed in
Python, and is not dependent on tuples.

> > And I still haven't
> > heard from anyone about why there isn't similar concern about immutable
> > dictionaries.
>
> People tend to use classes for this purpose. You can give a class a public
> interface (enforced or not) with only get_() methods, for instance. That
> gets you just about the same thing as an immutable dictionary would give
> you. Again, a dictionary tends to contain a larger number of homogenous
> objects, while an object tends to contain a smaller number of heterogenous
> objects.

That same technique could be used to argue against the need for tuples. Of
course, that's not often desirable in casual programs because it's somewhat
painful, and not all that necessary.

> Do you really feel that pain, then? Why don't you always use lists in your
> Python code, if you want to avoid the decision? That'd be effectively the
> same as what you're proposing

Well, it hasn't achieved the threshold of "pain", but I do seem to be using
lists in preference to tuples more often than I used to. And I still
speculate that life would be a bit better if I never had to think about
tuples vs. lists. There have been cases where I used tuples, to find out
later that I wanted mutability, so went back and changed. This sort of thing
happens in exploratory programming, so when in that mode one might want to
use lists unless one is really sure in advance that tuples are the right
thing.

By the way, when I get a run time error about trying to modify a tuple, it
never seems to be because I'm changing something I shouldn't. It's always
because it really should of been a list in the first place.

> If you don't do this, is this because you're
> afraid other programmers will complain about your code, or because you do
> believe there's something to decide about?

There are other possible motivations besides fear of criticism, such as the
desire to observe the spirit of the language. In doing that, it has occurred
to me that tuples might not provide enough benefit to warrant the additional
cognitive load. So far there have been zero responses in favor of my point
of view, so I'm in a very tiny minority  :-)

> If-everything-were-blocks-of-bytes-we-would-never-need-to-decide-ly yours,

Then we would have tcl :-)

Bob