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 -- https://mail.python.org/mailman/listinfo/python-list
