On 04/19/2015 03:08 PM, boB Stepp wrote:
On Sun, Apr 19, 2015 at 6:47 AM, Dave Angel <da...@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
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
