anything like C++ references?

Bengt Richter bokr at
Wed Jul 16 01:10:38 CEST 2003

On Tue, 15 Jul 2003 03:16:08 +0100, Stephen Horne <intentionally at> wrote:

>On 14 Jul 2003 23:31:56 GMT, kamikaze at (Mark
>'Kamikaze' Hughes) wrote:
>>  It looks like you've almost reached understanding, though you've been
>>given a bad start with a very idiosyncratic and monolingual
>>understanding of what "computer science" teaches--that was certainly not
>>in the classes I took, but apparently yours were different.
>Really. My computer science lessons were taught in a way that
>respected the source of most of the theory in mathematics -
>algorithms, Church's lambda calculus and that kind of stuff.
>What did your lessons teach?
>>  Since every operation in Python operates on pointers, there's no use
>>in having a special syntax for it.  You don't need all the * and & and
>>-> line noise.
>The point of the thread is not pointers - they are a side issue.
>When you use variables, you are using a concept from mathematics. In
>mathematics, variables bind to values. All values are immutable.
>Python binds variables to objects, not values. For immutable objects
>this is an unimportant implementation detail. For mutable objects, it
>breaks the mathematical principle of variables being bound to values.
Only if you persist in thinking of Python name bindings as variable bindings
in your sense. They are not. They are aliases. That concept exists in C/C++
and is e.g. a major concern in optimization.

>>  Stop trying to make Python into C/C++, and you'll be happier with it.
>>Or stop using Python, if you really don't like the design philosophy.
>>There are plenty of Algol-derived languages out there.  PHP and
>>especially Perl are more C-like in their internal logic, and you might
>>find them more pleasant.
>This is bogus.
>I don't want Python to become C or C++. I want Python to respect
>principles that come from mathematics and computer science. Not for
>reasons of theory pedanticism, but because the current system can and
>does regularly cause confusion and errors.
That always happens when you use the wrong theory to interpret your data ;-)
Quit projecting your "variable binding" idea onto Python's name bindings.
It doesn't fit. Not because it's bad, but because it's the wrong theory.

>The fact that Python claims to be a very high level language, and yet
>you have to worry about the binding of variables to objects -
Python's bindings are not about what you call variables. I think we should call
them by a different word, e.g., aliases. I.e., different names for the same thing.

>something that should be a low level implementation detail - has very
>real everyday implications.
>Respect the idea of variables binding to values and suddenly the need
>for pointers becomes more obvious. You cannot abuse mutable objects to
>fake pointer functionality (another everyday fact of Python
>programming) if the binding of variables to values (rather than just
>objects) is respected.
Quit it with this "respect" thing ;-) Python's name bindings just aren't
your variable bindings, and Python's names aren't variable names. They're
aliases. Persisting in calling Python's names variables-in-your-sense is disrespect ;-)

(See another post for a namespace (attibute name space of class NSHorne instances ;-)
that forces name binding to copied objects having equal values).

Bengt Richter

More information about the Python-list mailing list