[Tutor] lists, name semantics

[Dave Angel]

On 04/19/2015 03:08 PM, boB Stepp wrote:
> 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 in a swap file, a disk file, or some other media.

> 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?

Somebody keeps track, but the address is not necessarily constant, and 
not necessarily stored in any references.  The references (bindings) are 
abstract, and the details are unimportant to the user.  For example, the 
jython system does not use addresses at all.  And an object gets moved 
around from time to time without its references knowing it.

> 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?

No, we use one of your many labels to find you.  And if no labels exist, 
you quietly cease to exist (garbage collection).  But understand that a 
"label" in this sense need not be some alpha string.  It might be a slot 
in some collection, like the way I described list.
>
>> 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.

The distinction between deep and shallow was already made, by better 
people than I.  I was trying to explain it in terms of a working model 
that would let you predict what will happen in each circumstance.  A 
slice only copies the bindings in the list, it doesn't care what they 
are bound to.  It's shallow because it's shallow.



-- 
DaveA