Mutable objects inside tuples - good or bad?
Chris Angelico
rosuav at gmail.com
Sun Apr 6 04:25:36 EDT 2014
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
More information about the Python-list
mailing list