The future of Python immutability
steve at REMOVE-THIS-cybersource.com.au
Sun Sep 6 01:48:03 CEST 2009
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
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
Okay, I accept that if you focus only on the similarities and completely
ignore the differences, Python name binding is just like pointer
>> 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
If you mean that Python threads lack the ability to have local variables,
that's not true at all.
More information about the Python-list