Tuples -- who needs 'em

[Bob Alexander]

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

Thanks for your well-considered comments, but we still have our differences
:-)

> the idea of immutable
> objects is that assigning them is exactly the same behavior as copying
> them. That's something an easy thing to think about; for instance with
> strings and numbers. The idea here is that tuples allow you to think that
> way about lists.

Well, immutable objects render the copy vs. reference semantics moot, since
you can't change them anyway. With true copy semantics, the receiver of the
copy can change the object without affecting the originator's object. But I
agree that you can safely pass around references to immutable objects
without fear of their being modified -- I guess that's the point of
immutable.

> Okay, but it's generally practiced in idiom. Language constructions can
> exist that partially support idiom, but not enforce it, right? Here the
> idea is to bind various immutable things together to something that's
> still immutable. The immutability of non-tuples isn't there to
> catch 'mutation' errors (as that there is no way to actually mutate them
> at all). It's there for the nice semantics. Tuples supply the syntax and
> semantics to do this with multiple immutable things. Your problem arises
> because there's something very similar to a tuple, a, list, which does
> support mutation syntax. Would you have the same trouble with immutable
> strings if there were mutable strings in the language? And why not?

You might ask, "why doesn't Python have both mutable strings and
immutable?". Some languages (like Java) do. One answer: having both flavors
doesn't buy us much, even though there might be an occasional use for a
mutable string. I'm glad we don't have both flavors of string. Similarly, I
don't think we need both mutable and immutable sequences. But in the case of
sequences, it's the immutable flavor that doesn't buy us much.

By the way, for those who contend that tuples are a good way to pass around
groups of heterogeneous elements, I contend that they have some drawbacks.
Take the example of "point" that was previously used in this thread. Create
a point p = (11, 22). How do I refer to the elements? As p[0] and y[1]. Hmm,
which is x and which is y? Wouldn't it be better if I could reference the
elements by name, x.x and x.y? Some languages have record types where you
can declare "record Point(x, y)", create an object as Point(11, 22), and
refer to the elements as p.x and p.y. A language supporting this is Icon,
and records are roughly as efficient as Python's tuples even though the
elements have names. Even in JavaScript you can construct something like a
tuple (but not immutable) with named elements using the same syntax as
Python dictionary "literals" {x: 11, y: 22}. Although I clearly prefer
Python as a language over JavaScript, that is a nice feature. Of course, you
can effect the same behavior in Python, but not so conveniently. I think
that tuple-type objects with named elements are superior to numbered
elements for groups of heterogeneous elements, and that immutability is not
often necessary and even sometimes an inconvenience.

> But the idea here is that heterogeneous sequences of a small number of
> immutable things (which behave with a semantics indistinguishable of
> pass-by-value) should also be such a thing. Python passes everything
> by reference. But for some things, such as numbers and strings,
> pass-by-value is actually more interesting. So there we get immutability
> to support that.

Yes, it's true that if you pass a collection to a function and don't change
it, it's much like pass-by-value.

> I do think the Python language supports the homogeniety idea. Just because
> Python supports heterogeneous lists doesn't mean you should be using them
> all over the place.

But, why not? How is it damaging? When I first discovered a language that
did not require homogeniety (is that a word?) in lists, I though of it as an
advantage, not a drawback. (That was Snobol4, a *long* time ago!) I still
feel that way.

Some of my following responses reflect the fact that I haven't bought into
the if-a-sequence-is-a-list-it-must-be-homogeneous concept.

> > As you say, the functional programming paradigm can be nicely expressed
in
> > Python, and is not dependent on tuples.
>
> Some of it can be nicely expressed, some can't be, and as you say, it's
> not dependent on tuples. But you mentioned you knew no languages with
> the concept of immutable lists, and I mentioned functional programming
> languages. I did already say Python doesn't work this way, so you don't
> have to tell me what I just told you. :)

Oops, sorry. I do that sometimes :-)

> > There have been cases where I used tuples, to find out
> > later that I wanted mutability, so went back and changed.
>
> Hm, I rarely if ever seem to run into this. If I need mutability of
> a set of heterogenous objects I tend to use a class. There may be a
> switch from tuples to classes, but not often from tuples to lists, I
> think.

Well, since I don't have an aversion to heterogeneous lists, it's kind of
the same thing  :-) Yes, the proper choice is class, but a small list (or
tuple) is much more convenient (for the coder, BTW, not the reader :-). And,
after all, Python is a "rapid development" language where convenience is
highly valued. Just don't forget which element number is which! Or if you
change the order later, don't forget to change all the references.

> Perhaps you shouldn't think 'tuples or lists', but 'tuples or classes',
> then?

If tuple is a super-convenient-quickie substitution for class, then, to me,
list is just a mutable version of the same concept. (And neither of those is
as expressive as using a class.) You're suggestion is change tuple-to-class,
in my example I changed tuple-to-list. Either way is a different means to
the same end (yours is more correct, but more laborious). One might start
out using tuple not realizing that he/she would later want mutability for
that particular use. Then he/she has to change existing code. In a language
focused on rapid development, that is not good. I guess the moral is: if
you're not 100% sure, use list :-)

And if there were only one tuple/list datatype, we'd never have to decide
about it during programming, or go back and change it when we don't
anticipate correctly, or explain the difference to Python newbies, or have
FAQ items about it, or have discussions such as this :-)

-- Bob