Are tuple really immutable?

[Chris]

Hi

Consider the following tuples:

t = ([1],[2])
u = (1,2)
v = ('1','2')
t ([1], [2]) u (1, 2) v ('1', '2') t.__hash__() Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: list objects are unhashable u.__hash__() 219750523 v.__hash__() -1786881095 d = dict()
d[t] = 't' Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: list objects are unhashable d[u] = 'u'
d[v] = 'v'
d {('1', '2'): 'v', (1, 2): 'u'}

t, u and v are all tuples. t and v elements are sequences.
Yet, t cannot be a dictionnary key because its elements are mutable.

1) Given a tuple, how can I know if it can be a dictionnary key or not?

Of course I could call __hash__ and catch for a TypeError exception,
but I'm looking for a better way to do it.

2) Would it be possible to have a "ismutable" function or method? Like: t.ismutable() True, well maybe not... u.ismutable() False u.ismutable() False

3) In this example, is t considered mutable or not?
"Tuple are immutable" says the doc, but: t[0].append(0)
t ([1, 0], [2])

The tuple is immutable but its elements can be mutable: I tend to think
that it means that the tuple is mutable. Indeed, it changed!

4) Even more confusing: I had the following strange result:
(with both Python 2.3.3 and 2.4) t[0]+=[1] Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object doesn't support item assignment t

([1, 0, 1], [2])
There was an exception, but the list was still changed!?

Chris

[John Roth]

"Chris" <ch**********@g mail.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

Hi
3) In this example, is t considered mutable or not?
"Tuple are immutable" says the doc, but:

t[0].append(0)
t ([1, 0], [2])

The tuple is immutable but its elements can be mutable: I tend to think
that it means that the tuple is mutable. Indeed, it changed!
Well, it did and it didn't. If you went in and did an
id() on each element, you'd discover that the actual
objects didn't change: the exact same ids were in
the exact same slots before and after. What you're
seeing is the way the str() and repr() functions print
the values of embedded objects, not the ids.

4) Even more confusing: I had the following strange result:
(with both Python 2.3.3 and 2.4) t[0]+=[1] Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object doesn't support item assignment t

([1, 0, 1], [2])
There was an exception, but the list was still changed!?

I consider that an error, but I've had several people
tell me that it's the way it's supposed to be.
I simply quit trying to get the point across.
As far as I'm concerned, the behavior is simply
wrong. Since mutating the object didn't change
the id, it shouldn't try to replace the object in
the tuple.

John Roth
Chris

[Fredrik Lundh]

"Chris" wrote:

1) Given a tuple, how can I know if it can be a dictionnary key or not?

Of course I could call __hash__ and catch for a TypeError exception,
but I'm looking for a better way to do it.
calling hash(obj) is the only sane way to figure out if calling hash(obj)
will work.
2) Would it be possible to have a "ismutable" function or method?
objects are mutable only if they have some method (visible or __hidden__)
that can be used to modify their contents. from the Python runtime perspec-
tive, objects are objects.
3) In this example, is t considered mutable or not?
"Tuple are immutable" says the doc, but:

t[0].append(0)
t ([1, 0], [2])

The tuple is immutable but its elements can be mutable: I tend to think
that it means that the tuple is mutable. Indeed, it changed!
as map(id, t) can tell you, the tuple object itself wasn't modified.
4) Even more confusing: I had the following strange result:
(with both Python 2.3.3 and 2.4) t[0]+=[1] Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object doesn't support item assignment t

([1, 0, 1], [2])
There was an exception, but the list was still changed!?

that's a silly side-effect of how "+=" is defined for lists; the "+" part of the
expression works, and modifies the target object, but the "=" part fails.

</F>

[Alex Martelli]

Chris <ch**********@g mail.com> wrote:
...

3) In this example, is t considered mutable or not?
"Tuple are immutable" says the doc, but:

t[0].append(0)
t

([1, 0], [2])

The tuple is immutable but its elements can be mutable: I tend to think
that it means that the tuple is mutable. Indeed, it changed!

Maybe the last page of
<http://mail.python.org/pipermail/python-list/2002-April/099227.html>
can help with this conceptual issue.
Alex

[Terry Reedy]

Chris <ch**********@g mail.com> wrote:
...

3) In this example, is t considered mutable or not?
"Tuple are immutable" says the doc, but:

>>> t[0].append(0)
>>> t

([1, 0], [2])

The tuple is immutable but its elements can be mutable: I tend to think
that it means that the tuple is mutable. Indeed, it changed!

No, not in the way intended by the word 'mutable'. A tuple is like an
ordered club roster written in indelible ink before the time of whiteout.
The members of the club may change (change jobs, residence, relationships,
etc) but the roster remains the same: same members, same ranking.

Terry J. Reedy

[Chris]

I'm suing Google Groups (beta) which has a treeview and my thanks were
a reply to Fredrik Lundh. In fact I simply clicked a "reply" link below
his post.
Of course you all helped me to better understand the
"mutable/immutable" concept but Fredrik Lundh deserves more thanks
since he replied to all my questions ;-)

Chris