Tuples -- who needs 'em

Martijn Faassen m.faassen at vet.uu.nl
Thu Apr 6 06:24:38 EDT 2000


Alexander, Bob <BobAlex at uppercase.xerox.com> wrote:

> m.faassen at vet.uu.nl [mailto:m.faassen at vet.uu.nl] wrote:

>> But tuples are nice in particular for their *syntax*. With tuples, you
>> can do:
>> 
>> def foo():
>>     return 1, 2, 3, 4
>> 
>> first, second, third, fourth = foo()
>> 
>> I think this is nice syntax. Without tuples it'd not be as 
>> nice. It's not so much about efficiency. This pattern occurs all
>> over Python.

> I like that syntax too. If tuples and lists were unified, that bracket-free
> syntax could also be used for the list/tuple datatype, and nice syntax you
> mention would not change.

Except that you can suddenly do this:

results = foo()
...
results.append(5)
...
first, second, third, fourth = results # error

That's could be a bad thing, though of course Python isn't typesafe
in any case. The usage of tuples is however different, supported by 
syntactic difference. A tuple tends to contain a few heterogenous things,
while a list tends to contain a larger number of homogenous things.

[snip]
>> But this is less symmetrical, and since lists are mutable, 
>> this may go wrong far more easily.

> I am wondering where the serious concern about mutable lists comes from, as
> it is a pattern in the responses I've gotten on this topic. For me, the
> immutable list is a relatively new concept, since I can't think of many
> other languages that have it.

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.

> I'm a programming-language-design kind of
> person, and I never really saw mutable lists as a problem that needed
> solving. I've used many Python-type languages that have mutable lists but
> not immutable ones, and if I don't want the elements to change they don't
> change -- I simply avoid the x[i] = y construct :-) 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.

> Anyway, it seems to me that most of the tuple advantages we enjoy could and
> should still exist with a merged tuple-list type, and the only possible
> drawback is the loss of an immutable sequence type. The gain, though, is one
> less decision that we must frequently make (between tuple and list) while
> programming.

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

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

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



More information about the Python-list mailing list