Transitivity and direction of "binding" (was Re: Comments requested: brief summary of Python)

[Anton Vredegoor]

Peter Hansen <peter at engcorp.com> wrote:

>Is it "binding the object to the name", or is it "binding the name
>to the object".  
>
>Or both?  
>
>Or neither?  
>
>Why?
>
>And does it matter? ;-)
>
>(Seriously though...)

IMHO this depends on whether one sees the set of currently unnamed
Python objects as existing in some form or another inside the garbage
collection namespace or as residing in a space of unbroken symmetries
where they can be lifted out of by describing their shape.

In the first case objects have a kind of Platonic existence even
*before* they are bound to a name, and the name binding process just
provides us with a reference to this object. For example if there is
an object with name 'a' and value 1 then the operation of adding 1 to
this name is not changing the value of the Platonic object 1 into 2
but instead the name 'a' is now bound to *another* unchangeable
Platonic object, in this case the object with value 2.

This is confusing C-programmers endlessly since they are expecting to
change the value of some memory location while having the name 'a'
point to this same location invariably, until explicit instructions
change that.

In the second case where Python objects are seen as "created" by
carving them out of the undefined background space of the universe
there is even more room for confusion. 

The Python interpreter cannot execute magic or create information out
of raw quantum uncertainties because it has to operate within a
limited memory and computing environment. So it just stamps out
objects according to some template, fooling us into thinking that the
objects could have every conceivable shape, while in fact there are
serious limitations. 

Next it tries to hide that fact instantly and acts as if everything is
all right and we live in the nice and overseeable Platonic universe
that was described before.

So, well, yes, it does matter, but not here but for example in
newsgroups as comp.ai.philosophy where subjects like mental
representations -finding the cells in your brain that code for your
grandmother- are much more current than here on comp.lang.python.

The chance of finding the actual representation of an object inside
the Python interpreters' underlying hardware is much better than
solving the comp.ai.philosophy problems because of the less flexible
stamping mechanism the interpreter uses compared to humans. 

That may well change in the future however and we might have to deal
with the same humunculi as the philosophers have to concern themselves
with. Until then we assume that we live in a Platonic universe and can
use unit testing to scare the occasional hidden bug out of our code,
fully aware that it's our computer that really runs the interpreter,
but it will let us tinker for just a few more moments ...

Anton