anything like C++ references?

[Ian Bicking]

On Sun, 2003-07-13 at 12:51, Stephen Horne wrote:
> On 13 Jul 2003 12:19:08 -0400, aahz at pythoncraft.com (Aahz) wrote:
> 
> >Whether one can mutate a specific object is simply an
> >attribute of that object, rather than requiring a different syntax.
> >Trying to focus on the mutable/immutable distinction is what causes the
> >mental blowup -- keep your eye on the objects and bindings and you're
> >fine.
> 
> That's exactly it - you have to focus on whether an object is mutable
> or immutable for that exact reason.

No you don't!  Mutable and immutable objects act the same with respect
to assignment.  However, because you cannot change a immutable object in
place, to get a different value you must rebind.  You must *use* mutable
and immutable objects differently -- but that is not surprising, because
they are obviously very different objects!  You have to use integers and
lists differently in part because one is mutable and the other isn't --
but mostly because one is a number and the other is a list.  Different
objects are different!

Python is not novel in the way it deals with variables.  Scheme and
Smalltalk, for instance, act exactly the same, as do many other
dynamically typed languages (though there are different opinions on
whether strings should be mutable -- but it's agreed there has to be
some immutable string-like type, e.g. symbol).  The reason you are
getting this reaction is that anyone that comes from those backgrounds
thinks you are crazy, as does anyone who has embraced the Python model. 
This isn't a funny little feature, this is the way all strong,
dynamically typed languages work.

> While I admit I'm not sure, I believe that in early versions of Python
> immutable values literally were copied. Mutable types were made
> mutable because of efficiency concerns about copying overheads that
> would occur otherwise. If an object is large enough that it is
> worthwhile modifying items within it in-place then it tends to be
> worthwhile trying to avoid copying overheads, even though these two
> aspects of 'mutability' are actually quite distinct in principle.

The problem you have is you are still thinking of variables as slots,
which is not correct.  Variables in Python are bindings.  Assignment
never copies anything, or creates anything except for changing the
variable to point to a different address location.  *Every* Python
assignment (a=b) is like the C assignment (a=&b).  

> Tell me one case where it is sensible for a function to behave such
> that whether the caller sees a change in a variable it passed as its
> argument should depend on the type.

Generally a function takes either immutable values (e.g., ints and
floats) or mutable values for a certain argument.

However, there is a class of operations which are generally operate in
an immutable manner, that is, create copies of the objects instead of
changing them in place.  So even though lists are mutable, list
concatenation does not mutate, and in general adding two things (with +)
will not mutate either object.  Immutable values, by design, do not have
the same methods and operations as the mutable counterparts (or at least
the mutating methods of those mutable objects).  *That* would be a
design bug.

> Tell me one case where an object storing values should care about
> callers mutating values it holds *only* for certain types.

Objects don't *store* values, they *refer* to values.  You are still
thinking like you're in C (or C++).  This is why you are having a
problem.

  Ian