anything like C++ references?
tim.one at comcast.net
Sun Jul 13 22:57:18 CEST 2003
> The fact is that 'assignment' has a common meaning separate from the
> choice of programming language,
Well, that's not a fact, although there may be much commonality among the
(necessarily few, if you believe this) programming languages you've used.
Python's assignment semantics are in fact common among languages
higher-level than those of the Fortran/COBOL/Algol/C ilk. For examples,
Lisp, SNOBOL4, Scheme, Smalltalk and Icon are (very) much like Python in
this respect. So is Java in the end, although the underlying machinery is
more complicated there.
> and that the way Python handles name binding means that meaning is not
> respected by Python for mutable objects.
Python's assignment semantics don't vary according to object type.
> Python, however, does not respect this meaning.
This doesn't say more than that Python works differently than the languages
you've used. It really isn't a question of respect <wink>.
> It uses an arbitrary distinction based on whether or not the object
> has internals that can be usefully in-place modified, and uses that
> distinction to vary the effect of assignment in an arbitrary,
> inconsistent and error-prone way.
It's deliberate and thoroughly consistent. Any assignment semantics are
error-prone in some contexts, though (Python's included -- side effects are
like that). The simplicity and absolute consistency of Python-style
assignment semantics are probably easiest for first-time programmers to pick
up, and certainly dead easy for people coming from Lisp (etc) to pick up --
people coming from C (etc) often struggle with inappropriate expectations at
> The need for a distinct tuple type is a symptom of the arbitrary
> nature of this.
Python's assignment semantics have nothing to do with mutability versus
immutability. The latter is a type-dependent distinction; assignment
semantics in Python don't depend on object type in any way.
> I've already posted too much on this, so this is going to be the end
> to it. But Pythons semantics with regard to mutable and immutable
> objects are simply bizarre.
Hmm. Mutable objects can be mutated, and immutable objects cannot be
mutated. That doesn't seem bizarre.
> A historic justification may be plausible and backward compatibility
> is then an important issue, but I really cannot accept claims that
> Python is doing the right thing here.
Well, I can assure you Guido wouldn't change anything about Python's
assignment semantics if were able to do it all over from scratch. That's a
puzzle for you to work out, then: is Guido unique, or are all Dutch people
that stupid <wink>?
More information about the Python-list