anything like C++ references?

[Stephen Horne]

On 13 Jul 2003 14:48:09 -0500, Ian Bicking <ianb at colorstudy.com>
wrote:

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

In computer science, a variable is a named binding to a value.
Operations on that variable may rebind it to a different value, but
values don't change behind your back. A pointer is, in effect, a value
which indirectly refers to another (possibly anonymous) variable. A
pointer is something you specifically request, and by doing so you
allow that the 'variable' being indirectly referenced may be modified
by something else that has no direct access to your pointer value (via
your named variable or via copys or pointers-to your pointer held
elsewhere).

Python should respect that.

If you claim that it does, then the values to which we currently
associate the type name 'list', 'dictionary' and 'class instance' are
badly named. They should be called 'pointer to list', 'pointer to
dictionary' and 'pointer to class instance'. And if you want to call
those references and make the dereferencing implicit, fine. Equally,
if you want to implement variable binding using references and using
copy-on-write to implement lazy copying (which does not violate the
standard computer-theory semantics of the binding to values - only the
binding to the implementation of values ie memory locations) then
equally fine.

However, even if the names included the 'pointer to' prefix so that
they actually described the real behaviours of the values, this still
raises two important questions...

1.  Why are the values of mutable objects always forced to be accessed
via a pointer (or reference or whatever)?

Note that I am referring to a computer science, semantic
pointer/reference/whatever - not to any pointers or references that
may be used in the implementation of the binding of variables to
values. The use, behind the scenes, of lazy copying as an optimisation
is irrelevant to the computer science principles.

2.  Why is there no way to reference an immutable object via a
pointer, other than stuffing it into a mutable object designed for
some purpose other than simple pointer behaviour?

The truth is that this system is arbitrary, and that therefore this
excuse is invalid.

>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).  

The problem is that you are confusing implementation with semantics.
The meanings of 'variable', 'value', 'assignment' etc are defined by
computer science. Whether you arbitrarily change the meaning of
'assignment' or whether you arbitrarily change the meaning of
'variable', it amounts to the same thing.

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

You miss my point. Your argument would equally apply to the need for
an integer-specific division operator, for instance. Its all about how
one function reacts in response to varying input. If you pass a
mutable value to a function which expects an immutable one, you get an
error. If you pass an immutable value to a function which expects a
mutable one, you get an error. There is no good reason for a function
to react to the distinction as evidenced by your own observation that
what actually happens (and what should happen) is that you have two
distinct variants of the function.

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

No it is not. I'm thinking in terms of computer science, in which
terms like 'variable', 'value' and 'assignment' are abstract concepts
independent of the way in which they are implemented in a programming
language.

One way or the other, Python is currently choosing not to respect the
computer science definition of those terms. It may have historic and
backward-compatability reasons, but that does not change the facts.
This deviation from computer science definitions, whatever the excuse,
is arbitrary, confusing and error prone. That is my problem.