On Sun, Apr 6, 2014 at 5:55 PM, Devin Jeanpierre <jeanpierr...@gmail.com> wrote: > On Sun, Apr 6, 2014 at 12:25 AM, Gary Herron > <gary.her...@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 -- https://mail.python.org/mailman/listinfo/python-list
