Mutable objects inside tuples - good or bad?

[Chris Angelico]

On Sun, Apr 6, 2014 at 5:55 PM, Devin Jeanpierre <jeanpierreda at gmail.com> wrote:
> On Sun, Apr 6, 2014 at 12:25 AM, Gary Herron
> <gary.herron at islandtraining.com> wrote:
>> On 04/05/2014 11:53 PM, John Ladasky wrote:
>>>
>>> I find this programming pattern to be useful... but can it cause problems?
>>
>> No.
>>
>> What kind of problems are you considering?  It won't break Python. It's
>> perfectly legal code.
>
> Agreed. Putting mutable objects inside tuples is common and totally OK.

There are many programming habits that can cause problems, even though
they won't break Python and are legal code. :)

>> The tuple c is still immutable, consisting of two specific objects, and (as
>> always) without regard to the specifics or contents of those two objects.
>
> You can choose to define mutability that way, but in many contexts
> you'll find that definition not very useful.
>
> c is such that you could have another variable d, where the following
> interpreter session fragment is easily possible:
>
>>>> c == d
> True
>>>> foo(c)
>>>> c == d
> False

What you're looking at here is hashability, not mutability. Compare:

>>> a = (1,2,3)
>>> hash(a)
2528502973977326415
>>> b = ([1],[2],[3])
>>> hash(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'

Both tuples are immutable, but the former is hashable because all its
members are hashable, while the latter is not. You can't trust that
equality with b is constant:

>>> c = ([1],[2],[3])
>>> b == c
True
>>> b[2][0]=4
>>> b == c
False

Going back to the original question, though: I do not believe that
putting mutable objects inside tuples is a problem. I've done it
frequently myself, and it's never caused confusion. So go right ahead,
do it if it makes sense!

ChrisA