Slices time complexity

[Chris Angelico]

On Tue, May 19, 2015 at 6:39 PM, Marko Rauhamaa <marko at 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