[Tutor] lists, name semantics

[boB Stepp]

On Sun, Apr 19, 2015 at 6:47 AM, Dave Angel <davea at davea.name> wrote:
> On 04/19/2015 12:07 AM, boB Stepp wrote:

[...]

>> I hope this is helpful, and, if there are any misstepps, that when
>> they are revealed both of our understandings will be enhanced!
>>
>
> Some of your knowledge of other languages is leaking into your explanation.
> When we talk of the language Python, we need to distinguish between how
> CPython happens to be implemented, how other Python implementations happen
> to be created, and how C++ (for example) implements similar things.  Some of
> the above use pointers, some do not.  The language Python does not.

I actually was being deliberately  *imprecise* in my use of technical
terminology.  But I see below that there are some nuances I need to
learn...

> So especially when talking of inner lists, we need to clarify a few things.
>
> An object has an identity, not a location.  That identity can be checked
> with the 'is' operator, or the id() function.  But it exists all the time.

But the object, in order to exist, must be stored in RAM somewhere,
doesn't it? Or is the real point that we are adding an abstraction
layer so we don't even have to think about where objects are
physically stored in RAM? So I am the object referenced by "boB" and
we don't care what my precise (x, y, z) coordinates are relative to
the planet Earth. If we need to find me or modify me we use my label,
"boB", to access me?

> Variables, as you say, do not contain an object, they reference it.  And the
> formal term for that is binding.  A name is bound to an object, to one
> object, at a time.
>
> Now some objects have attributes, which is to say names, and those
> attributes are bound to other objects.  So if we define a class, and have an
> instance of that class, and the instance has attributes, we can do something
> like:
>     obj.inst_name
>
> and get the particular attribute.
>
> Still other objects have unnamed bindings.  The canonical example is a list.
> A list object has a bunch of bindings to other objects.  Even though each
> binding doesn't have a specific name, it nevertheless exists.  And in this
> case we use integers to specify which of those bindings we want to follow.
> And we use a special syntax (the square bracket) to indicate which of these
> we want.

Ah, "unnamed bindings" was the concept I was talking around. I
realized these were there and were referenced by the square bracket
syntax, but I did not know what to call the concept.

[...]

> At this point, it should be clear what a shallow copy means.  If the
> original list's oneth item was a binding to another list object, *that* list
> object does NOT get copied.
>
> I don't like the term "inner list",  but I don't know if it's incorrect.
> It's just misleading, since to the slice operation, the fact that it's a
> list is irrelevant.  It's just an object whose binding is to be copied.

So the real point here is that there are two distinct copying
mechanisms, deep and shallow. The "inner list" could just have been
any other type of object, though if it had been an immutable type it
would not have made Peter's original interesting point.

-- 
boB