The future of Python immutability

[Steven D'Aprano]

On Sat, 05 Sep 2009 04:57:21 -0700, Adam Skutt wrote:

>> > so the fact "Foo" and "Bar" are immutable isn't enough to solve the
>> > problem.
>>
>> This is a side-effect of writing code that relies on global variables.
>> Global variables are generally a bad idea. Global constants are fine.
> 
> Nope, the variables don't have to be global to have this problem, they
> just have to be shared:

Yes, you're right, my bad. Globals are shared, but not all shared 
variables are global.


>> What do you mean by "variables"? Do you mean names?
> 
> In the case of python I mean the name and the value, since all variables
> in Python are pointers.

Let me see if I understand you... 

You say that by "variable" you mean the name and the value.

Then you say that all variables are pointers.

In other words... "all names and values in Python are pointers".

Either you're not explaining yourself correctly, or you're badly confused 
about Python. In Python, names are keys in namespaces, and values are 
objects. Possibly some Python implementations use pointers in some way to 
implement namespaces, or objects, but Python the language doesn't have 
pointers, and the Python virtual machine that executes Python byte code 
doesn't have pointers either.



> (Worrying about the difference though, is semantics)

Semantics are important. If we can't agree on what things mean, how can 
we possibly communicate?



>> What are pointer semantics?
> 
> Assignment to the variable causes it to point to another object (as
> opposed to assigning a new value to the current object, like a C++
> reference) and copying the variable does not create a copy of the
> referred object (which necessarily implies their lifecycles are
> independent).

I can *guess* what you mean by all that, but it's just a guess. You say 
"assignment to the variable", but earlier you said that to you, variables 
are names and values, so I'm left wondering if you mean assignment to the 
name, assignment to the value, or both. Likewise for copying the variable.

Here is my guess... you're pointing out the similarities between Python 
name binding and C pointers:

* when you bind a name to a new object, you cause the name be associated 
with the new object rather than mutating the existing object to become 
equal to the new object;

* assigning two names to a single object causes both names to be 
associated with the same object, rather than each name being associated 
with independent copies of the object;

while ignoring the differences between Python name binding and C pointers:

* Python names are keys, not numeric addresses, hence you can't perform 
anything like pointer arithmetic on them;

* objects in Python have no idea what, if any, names are associated with 
them, unlike C pointers, where you can always ask for the address of a 
variable.

Okay, I accept that if you focus only on the similarities and completely 
ignore the differences, Python name binding is just like pointer 
semantics.



>> Assuming you mean names must be forbidden from being rebound, no,
>> incorrect. It's only names which are shared between both threads which
>> must not be re-bound. If you have names local to the thread, you can
>> change them all you want without affecting any other thread.
> 
> What does it matter, seeing as Python lacks the ability altogether?

I don't understand what you mean. Python lacks the ability to do what 
altogether?

If you mean that Python threads lack the ability to have local variables, 
that's not true at all.




-- 
Steven