Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #59160 > unrolled thread

Re: 'isimmutable' and 'ImmutableNester'

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: 'isimmutable' and 'ImmutableNester' Chris Angelico <rosuav@gmail.com> - 2013-11-12 18:12 +1100
    Re: 'isimmutable' and 'ImmutableNester' Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-12 11:14 +0000
      Re: 'isimmutable' and 'ImmutableNester' Robert Kern <robert.kern@gmail.com> - 2013-11-12 14:00 +0000

#59160 — Re: 'isimmutable' and 'ImmutableNester'

On Tue, Nov 12, 2013 at 6:01 PM, Frank-Rene Schäfer <fschaef@gmail.com> wrote:
> A tuple is immutable but it may contain mutable objects. In larger
> hierarchies of objects it may become less obvious whether down
> the lines, there is some mutable object somewhere in the data tree.
>
> One can define a recursive function to check for immutability
> manually. However first, it may not be as efficient as if it was
> built-in. Second, the existence of a built-in function 'isimmutable'
> puts the concept of immutability some more into the spotlight.
>
> You might indeed implement some personal 'policy for copy/deepcopy'.
> But, how can you prevent the insertion of an object into the data
> tree which does not follow your copy/deepcopy convention? As soon
> as you allow members of type 'tuple' you must either check recursively
> or only allow ints and strings as tuple members.

>>> x=1,2,3
>>> hash(x)
-378539185
>>> x=1,2,[3]
>>> hash(x)
Traceback (most recent call last):
  File "<pyshell#424>", line 1, in <module>
    hash(x)
TypeError: unhashable type: 'list'

There's your recursive function!

def isimmutable(x):
    try:
        hash(x)
        return True
    except TypeError:
        return False

[toc] | [next] | [standalone]

#59181

On Tue, 12 Nov 2013 18:12:43 +1100, Chris Angelico wrote:

> def isimmutable(x):
>     try:
>         hash(x)
>         return True
>     except TypeError:
>         return False

I'm afraid that doesn't test for immutability. It tests for hashability, 
which is different.

No well-behaved mutable object can be hashable, but that's not to say 
that badly-behaved mutable objects won't be hashable. And every immutable 
object should be hashable, but that's not to say that some immutable 
objects might choose, for their own reasons, not to be hashable.

So your function is subject to both false negatives and false positives.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#59194

On 2013-11-12 11:14, Steven D'Aprano wrote:
> On Tue, 12 Nov 2013 18:12:43 +1100, Chris Angelico wrote:
>
>> def isimmutable(x):
>>      try:
>>          hash(x)
>>          return True
>>      except TypeError:
>>          return False
>
> I'm afraid that doesn't test for immutability. It tests for hashability,
> which is different.

I am going to nitpick below for nitpicking's sake, but I agree with this.

> No well-behaved mutable object can be hashable, but that's not to say
> that badly-behaved mutable objects won't be hashable.

That's not quite true. A well-behaved mutable may be (well-behaved) hashable as 
long as the allowed mutations do not affect the equality comparison. For 
example, in Python 2, all new classes are mutable by default, but they are also 
well-behaved hashable by default because their equality comparison is identity 
comparison. None of the mutations affect object identity, so the hash based on 
identity remains well-behaved.

> And every immutable
> object should be hashable, but that's not to say that some immutable
> objects might choose, for their own reasons, not to be hashable.

I would also dispute this. A tuple itself is immutable, but it may not be 
hashable because one of its contained objects is unhashable (whether due to 
mutability or something else).

> So your function is subject to both false negatives and false positives.

Agreed.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web