'isimmutable' and 'ImmutableNester'

Steven D'Aprano steve+comp.lang.python at pearwood.info
Tue Nov 12 06:33:27 EST 2013


On Tue, 12 Nov 2013 08:01:19 +0100, Frank-Rene Schäfer wrote:

> the existence of a built-in function 'isimmutable' puts the concept of
> immutability some more into the spotlight.

That is an argument against the proposal, not in favour. The concept of 
immutability doesn't need to be in the spotlight. It is rather 
unimportant. I've been using Python for over 15 years, and have never 
missed an isimmutable function. Once, when I was just starting with 
Python, I thought I'd try writing one. I found it harder than I expected, 
and less useful, and soon gave up. And have never missed it yet.


> 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?

I don't understand what this "policy" is supposed to be.


> As soon as you
> allow members of type 'tuple' you must either check recursively or only
> allow ints and strings as tuple members.

Why do you think you need to check at all? I think this is where we are 
talking past each other -- you seem to believe that testing for 
immutability is a critical piece of functionality which is missing from 
Python, as if lists had no way to query their length, or floats had no 
way to do multiplication. But that is not the case. Python has no 
isimmutable built-in function because, for the 20+ years that Python has 
existed, nobody who wanted it was willing to do the work to write it, and 
nobody willing to do the work thought it was important.

I believe that if you wish this PEP to go anywhere, you need to 
concentrate on two things:

1) demonstrating that checking for immutability is *necessary*

2) demonstrating that it is *possible*


-- 
Steven



More information about the Python-list mailing list