anything like C++ references?

[Stephen Horne]

On 14 Jul 2003 10:26:36 -0400, aahz at pythoncraft.com (Aahz) wrote:

>>>That's why I (and others) prefer to use "name" and "target" instead of
>>>"variable".  Would that assuage your ire?
>>
>>Not really, for reasons defined elsewhere. The problem isn't
>>theoretical - it is practical, as shown by the fact that people do
>>trip over it time and time again. I'm just saying that the problem
>>arises out of peoples intuition of how variables should work - an
>>intuition that matches very well with theory.
>
>People trip over pointers, too, even when they're explicit.  Heck,
>people have problem with the simple
>
>    a = a + 1
>
>no matter *what* programming language is used if they can't get past
>their high school algebra and understand that "=" is a *command* in this
>context.  The question is not whether newcomers get tripped up, but the
>extent to which the language can be easily defined in a consistent and
>rigorous manner.  Python passes that test quite handily, IMO.

Ah - but this is also Pythons fault. It has arbitrarily redefined the
meaning of a mathematics operator - presumably simply because C, C++,
Java, Basic and others have done this in the past.

C's rationale for this still amuses me. It was because there are more
assignments in a typical program than tests for equality. It was an
argument about numbers of keypresses!

Frankly, this is another thing that should not be done in a 'very high
level language'.

In BASIC, the operator is a shorthand for what was originally written
with a 'LET' command. Annoying, but at least the original form made
the point.

Personally, though, I'd go with Pascal on this one.

Similarly, if Pythons binding of variables to objects was used to
correctly implement a binding of variables to values - as happens in
mathematics - there'd be no confusion.

In another thread, hokiegal99 made a mistake where she expected the
string.strip method to literally change the name of a file on disk.
But was she being irrational? I don't think so. She had no doubt been
told, in effect, that Python variables bind to objects rather than
values. The object she was changing was 'the name of a file'. If
Python variables bind to objects rather than values, then that os.walk
method should be providing literally a list of the names of the files
- objects which literally refer back to the on disk file names. It
doesn't. It provides a list of representations of the names at a point
in time.

Of course in this case, binding to the object itself (or something
that implements a binding to that object) would be complex and
inefficient. I guess Python is just doing what is convenient for the
implementation.