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

Groups > comp.lang.python > #59158 > 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' Frank-Rene Schäfer <fschaef@gmail.com> - 2013-11-12 08:01 +0100
    Re: 'isimmutable' and 'ImmutableNester' Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-12 11:33 +0000

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

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.

[toc] | [next] | [standalone]

#59187

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

[toc] | [prev] | [standalone]

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

csiph-web