Slices time complexity

[Chris Angelico]

On Tue, May 19, 2015 at 10:42 PM, Steven D'Aprano
<steve+comp.lang.python at 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 <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.
>
> 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