On 5/8/2014 4:14 AM, Chris Angelico wrote:
On Thu, May 8, 2014 at 6:07 PM, Joseph Martinot-Lagarde
<joseph.martinot-laga...@m4x.org> wrote:
For me, names bound to values is the same concept as pointer pointing to
memory.
You are missing a level of indirection. In CPython, a name (always in
some namespace) represents a pointer to a pointer. The first pointer is
calculated as an offset from the base pointer of the namespace. For a C
array namespace (used for functions), the offset is constant (for that
function and namespace). For a python dict namespace, the offset is
calculated from the hash of the name, the size of the dict, and the
previous contents of the hash table. This complication allows the
namespace to grow and shrink. In either case, the second pointer if
overwritten to 'rebind' the name.
bar = foo copies the pointer and not the underlying memory.
It copies the second pointer of foo, in the underlying memory pointed at
by the foo's first pointer, to the memory pointed at by bar's first pointer.
>> This is not a foreign concept to C programmers.
Once one gets the indirection correct.
That is how it's implemented in CPython, after all... modulo the whole
refcounting thing, of course. But that's not strictly a part of the
definition of Python; it's just implementation. You could implement
Python on pencil-and-paper (aka a dry run), and as long as you have a
concept of names that reference objects, it's going to be fine.
For paper-aided mental execution, most people would not bother to
implement version and run dependent features, such as 'id()' and most of
the possible uses of 'is' (other than 'is None', etc.). For code that
also avoids such features, such shortcuts would indeed be fine.
"reference" might be done with a physical piece of string connecting a
Post-It note with a name to a box with the object's state, meaning
there's no way of copying any pointer, and it's still Python.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
