On Tue, May 19, 2015 at 6:39 PM, Marko Rauhamaa <ma...@pacujo.net> wrote: > For example, you could explain Python's object references as pointers > (memory addresses) if you considered that helpful. (That's how Lisp > textbooks often explain cons cells.)
Sorta-kinda-maybe, but if a C programmer's idea of pointers is invoked to explain Python's object references, the differences will start to be problematic: 1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are not just pointers to their first elements, and subscripting is most definitely NOT "add to pointer and dereference". 2) In fact, dereferencing as a whole isn't really a 'thing' either. At best, it happens automatically. 3) References actually mean something. Copying a pointer doesn't. Whether the Python you're using is refcounted (CPython) or mark-and-sweep (uPy, I think) or some other model, an additional reference to the same object will prevent it from being disposed of, which isn't the case in C. 4) A pointer is itself a value. You can pass a pointer-to-local-variable to another function and have that function change a local variable. 5) Furthermore, since a pointer is a value, you can have pointers to pointers, etc. Doesn't make any sense in Python. A closer comparison is the C++ "reference", which works kinda like pass-by-reference, kinda like a pointer, and kinda not like anything at all, really. But that's still not the same thing as HLL object semantics (the same semantics used by Python, Pike, ECMAScript, and a bunch of other languages). As long as you are aware that analogies are always limited, you can certainly use them as part of an explanation; but you do have to take care. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
