Why are tuples immutable?

[jfj]

Yo.

Why can't we __setitem__ for tuples?
The way I see it is that if we enable __setitem__ for tuples there
doesn't seem to be any performance penalty if the users don't use it
(aka, python performance independent of tuple mutability).

On the other hand, right now we have to use a list if we want to
__setitem__ on a sequence. If we could use tuples in the cases where
we want to modify items but not modify the length of the sequence,
programs could be considerably faster. Yes?

Enlighten me.

G.

[Steve Holden]

jfj wrote:

Yo.

Why can't we __setitem__ for tuples?
The way I see it is that if we enable __setitem__ for tuples there
doesn't seem to be any performance penalty if the users don't use it
(aka, python performance independent of tuple mutability).

On the other hand, right now we have to use a list if we want to
__setitem__ on a sequence. If we could use tuples in the cases where
we want to modify items but not modify the length of the sequence,
programs could be considerably faster. Yes?

Enlighten me.

G.

Well, the best answer may be "tuples are immutable because otherwise
there wouldn't be an immutable sequence type".

There have been many discussions on this topic (not that I'm blaming you
for being unaware of them), and normally when someone raises this topic
there's a flurry of nbew justifications for the existing behavior. The
bottom line seems to be that Guido wanted something that corresponds to
a mathematical tuple, which is an ordered collection of items of
(potentially) different types.

Of course there's nothing much to stop you using lists instead of
tuples, except the rare piece of code that insists on one or the other.

regards
Steve
--
http://www.holdenweb.com
http://pydish.holdenweb.com
Holden Web LLC [phone]

[Fuzzyman]

Wasn't part of the point, that function call returns ought to be
immuntable. Otherwise you can accidentally end up modifying objects
that are referenced in other places ?

Obviously tuples aren't the *whole* answer... but they help.

Regards,

Fuzzy
http://www.voidspace.org.uk/atlantib...thonutils.html

[Steven Bethard]

jfj wrote:

Why can't we __setitem__ for tuples?

It seems from your suggestions here that what you really want is a
single sequence type, list, instead of two sequence types: tuple and
list. Under your design, list would support hash, and it would be up to
the programmer to make sure not to modify a list when using it as a key
to a dict. The important thing to understand is that, while this is not
an unreasonable design decision, it's not the design decision that's
been made for Python.

Reading the docs and some of GvR's comments on python-dev, my
understanding is that, while a single sequence type would have sufficed,
the belief was that there were two mostly non-overlapping sets of tasks
that one might want to do with sequences. One set of tasks dealt with
"small collections of related data which may be of different types which
are operated on as a group"[1] (tuples), while the other set of tasks
dealt with "hold[ing] a varying number of objects all of which have the
same type and which are operated on one-by-one"[1] (lists).

Now, when you use a sequence as a key to a dict, you're operating on the
sequence as a group, not one-by-one. Given the above conceptions of
tuple and list then, it is natural to provide tuple with hash support,
while leaving it out of list.

Note also that tuples being immutable also falls out of the tuple
description above too. If you're operating on the sequence as a group,
then there's no need for __setitem__; __setitem__ is used to operate on
a sequence one-by-one.

I understand that you'd like a type that is operated on one-by-one, but
can also be considered as a group (e.g. is hashable). Personally, I
don't have any use for such a type, but perhaps others do. The right
solution in this case is not to try to redefine tuple or list, but to
write a PEP[2] and suggest a new datatype that serves your purposes.
I'll help you out and provide you with an implementation: =)

class hashablelist(list):
def __hash__(self):
return hash(tuple(self))

Now all you need to do is write the Abstract, Motivation and Rationale,
and persuade the people on c.l.py and python-dev that this is actually a
useful addition to the language.

Steve

[1]
http://www.python.org/doc/faq/genera...ist-data-types
[2] http://www.python.org/peps/pep-0001.html