anything like C++ references?

[Tim Peters]

[Stephen Horne]
> ...
> 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
first.

> 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>?