anything like C++ references?

[Stephen Horne]

On Mon, 14 Jul 2003 16:15:08 -0700, Tom Plunket <tomas at fancy.org>
wrote:

>Stephen Horne wrote:
>
>> All you have proven is that it is the distinction between types 
>> that get re-bound and those that don't (rather than the use of 
>> references) that is unnecessarily confusing and error prone.
>
>As the firestarter (I apologize for the flames that have
>erupted)

Strong feelings and opinions, IMO, but not really flames. At least
I've been willing to admit the mistakes I've made (or the ones I
recognise, anyway).

>, I must admit that even I know that this distinction
>does not exist in Python.  There aren't some types that get
>rebound and others that don't.

Yes - this was a major mistake on my part. I already confessed and
apologised elsewhere. My making mistakes in my arguments, however,
does not mean that my point is wrong. I believe that my current
arguments are not based on any mistakes I've made.

>I still feel that there's a wart of some sort, but it's not due
>to any inconsistency in the language, despite what I may have
>said before (I've been thinking about it a lot over the past few
>days).

Absolutely the point I've reached, though I've been forced to get a
lot clearer in my thinking to reach that point.

>> A Python user is interested in how an object behaves - not how it 
>> is internally implemented in the interpreter. Immutable objects 
>> don't behave as references - the internal use of references for 
>> immutable objects is basically a lazy copying optimisation and, 
>> apart from performace and a couple of other technicalities (e.g. 
>> the 'is' operator), has no relevance.
>
>Are they really technicalities, though?  I mean, a mutable object
>can be changed.  It's the same object, just changed.  Immutable
>objects, however, can't be changed.  You can get something that
>appears like changing it, but it's actually building a new thing
>and binding the label to that new thing.

Yes. But the thing being changed *is* an object, *not* a value. Values
are always immutable - basic fact of mathematics.

Variables in mathematics are bound to values. I think Python should be
implemented in a way that respects that.

Whether you use objects to represent values, or whether you use some
kind of symbolic representation is an implementation detail which
should be transparent to the user unless the user specifically
requests to deal with the object or whatever.

If I type...

>>> a = [1, 2, 3]
>>> b = a

Then in my mind, the point is that both variables get bound to the
value '[1, 2, 3]'.

The fact that the binding to values might be implemented using binding
to the same object at this point should be, to me, a low level detail.

If I now type...

>>> b[2] = 4

Then the variable b should now be bound to the value '[1, 2, 4]'. That
is the whole point of what I've done. However, the fact that it was
achieved by modifying a part of an object is an implementation detail.
It should not affect the *value* bound to the variable a. In other
words, a new object should be created at that point - a copy of the
original - which would then be modified. That way, the mathematical
concept of variables being bound to values would be respected.

This is not difficult to achieve. The implementations of the C++
standard library that I've seen use exactly the same copy-on-write
mechanism for strings. This method implements a lazy copying
optimisation without violating the concept of variables being bound to
values. That is, the hidden use of pointers or references in the
std::string class is an implementation detail that you don't have to
worry about as a programmer. The programmer worries about the
application - not the low level details of the implementation of the
language or library.

But, like I said before, this isn't about imitating C++. It's about
respecting the common definitions of 'variable', 'value' etc from
mathematics and computer science - something that people do seem to
intuitively expect until the Python way is beaten into them.

To me, 'Pythonic' expresses 'doing the right thing'. In this case, in
my view, Python does the wrong thing and expects everyone to get used
to it.