On Tue, May 19, 2015 at 10:42 PM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Tue, 19 May 2015 06:50 pm, Chris Angelico wrote: > >> 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. > > Chris, that is one of the best explanations for why "references equals > pointers" is *not* a good explanation for Python's behaviour. I may have to > steal it :-)
:) They say that turnabout is fair play. I stole your "Python vs MATLAB" python-tutor post about call-by-value vs call-by-reference vs object semantics for years (until some other pages picked up the same content). Go for it! That said, though, I was specifically referring to C's pointer semantics. As Gregory pointed out, Pascal has rather different pointer semantics; but if you're talking about Python references and considering using any concept of object addressing and pointers, it's most likely going to be something similar to C/assembly, where a pointer is a dereferenceable integer storing an offset into memory. (But don't even get *started* on near vs far pointers, code vs data segments and the thunks required to transform between them, memory-mapped disk, virtual segments, overlapping segments, shared memory, memory-mapped I/O, and all those other things that C programmers sometimes contend with. Fun, but hardly anything to do with Python objects. :) ) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
