Tuples -- who needs 'em

[Martijn Faassen]

Bob Alexander <bobalex at home.com> wrote:
> "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  :-)

That's of course true; I already mentioned that the 'protection' argument
isn't that strong, as Python is dynamically typed anyway.

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

Okay, I'll extend my problem description:

results = foo()
bar = results
bar.append(5)

That can't happen with tuples, can happen with lists. Of course I haven't
made any research on whether it does happen, but 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.

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

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?

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

Okay. 

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

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.

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

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

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

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

Right, since it's painful to do it for things like x,y coordinates, 
there's this nice thing, called the tuple. :) 

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

It's an interesting speculation. I'm learning a lot here by trying to
come up with the various arguments there are for tuples. I think it's more
than just the dictionary key argument.

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

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

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

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

Why a list? Is it a collection of homogeneous objects, then?

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

Okay, right, I should've said that, sorry for expressing myself poorly. 

> In doing that, it has occurred
> to me that tuples might not provide enough benefit to warrant the additional
> cognitive load.

Perhaps you are trying to switch between the wrong things? Could you
supply us with some examples?

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?