'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