anything like C++ references?

Bengt Richter bokr at oz.net
Tue Jul 15 03:17:52 EDT 2003


On Tue, 15 Jul 2003 04:28:21 +0100, Stephen Horne <intentionally at blank.co.uk> wrote:
>On Mon, 14 Jul 2003 16:15:08 -0700, Tom Plunket <tomas at fancy.org>
>wrote:
[...]
>>
>>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.
Too many words that I don't understand ;-/

Ok. There seem to be some entities you call "values" and some you call "variables."
>
>Variables in mathematics are bound to values. I think Python should be
>implemented in a way that respects that.
Now you are apparently saying that there is at least one relationship possible between
"variables" and "values" -- namely being "bound."

How do we know that a given "variable" is "bound" to a given "value?"
I guess one way would be to introduce the idea of an ordered pair, produced say by a
constructor "Pair", and also a set of ordered pairs defined as the binding set. Then if
Pair(variable,value) is in the binding set, we can say variable and value are bound.

Note that this is entirely abstract; representation is a separate matter. "variable"
is a single entity, presumably belonging to the set of possible variables.

>
>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.
>
Now we apparently have a recognizably different entity "object" which I'd like to know
the meaning of, not to mention some kind of relations "object"<->"represent"<->"value"
and "symbol"<->"represent"<->"value."

To start, I would propose that all the words should refer to some abstract entities or
relationships, and then that we carefully consider various concrete representations
that may be put in correspondence, perhaps also in terms of a set of ordered pairs.

I'm too tired right now though ;-/

>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]'.
Ok, I infer that your take "a" and "b" to represent "variables." And
you are proposing that "'[1, 2, 3]'" represents a "value", and
that the first statement creates a binding. say (a, '[1 2, 3]') in the binding set.

The second statement will presumably produce another binding (b, <??>) in the binding set.
Now that means we have to decide what "a" evaluates to in "b = a." If it's just a,
we get the binding (b, a) but that would say that variables can be part of the set of possible values
(i.e., variables per se, not e.g. string representations). That's not how it works, though.
Evaluating a implies finding its associated value in a (variable,value) pair in the binding set.
So the new binding should be (b, '[1, 2, 3]') -- i.e., the same identical value as bound to a.
So far this is just how python works.
>
>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
Aha. Maybe "variable" is a misnomer that you should not use when reading
python assignment statements. E.g., say "alias" instead, and read "b=a"
as "b is now an alias for the same entity as a is an alias for."

The syntax is like an optical illusion that can be seen more than one way,
and you are projecting a non-python view onto the syntax, which is interfering
with seeing the other view ;-)

>words, a new object should be created at that point - a copy of the
That's a "should" for another language, it's not what Python is designed to do.
>original - which would then be modified. That way, the mathematical
>concept of variables being bound to values would be respected.
>
Why don't you respect the possibility of a language that is *designed* to deal
with entities and relationships in ways you are not used to? ;-)

>This is not difficult to achieve. The implementations of the C++
The difficulty is not really relevant. It's not a goal for this language ;-)

>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
There you go again ;-) I could as well say that it's about "respecting"
that Python is not designed to do what you are used to and thus does not use
"assignment" the way you are used to, most likely because it doesn't really have
"variables" in the sense that you are used to.

Why assume because some notion isn't used that it means disrespect? If you
read "variable" where you should be reading "alias" perhaps you are misconstruing
what you are reading, and are merely uncomfortable because the mental model you
are using to organize your perceptions doesn't fit. It's like saying a python should
respect accepted ideas of locomotion and have legs, because everything you're used
to that moves on the ground has legs ;-)

>mathematics and computer science - something that people do seem to
>intuitively expect until the Python way is beaten into them.
You mean until the burn-in from their first over-repeated viewpoint exposure fades ;-)
>
>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
Expand your set of views. I think you will find one where you will see Python
as doing the right thing, for the most part. ;-)
>to it.

Regards,
Bengt Richter




More information about the Python-list mailing list