Path: csiph.com!usenet.pasdenom.info!nntpfeed.proxad.net!news.muarf.org!news.roellig-ltd.de!open-news-network.org!border2.nntp.ams1.giganews.com!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <555b2fa9$0$12996$c3e8da3$5496439d@news.astraweb.com>
References: <9ceklad15llnv3npejq9iuh91soci8aeqo@4ax.com> <mailman.114.1431978628.17265.python-list@python.org> <7ea01590-a559-46e5-abf5-29622e39aae7@googlegroups.com> <555ac697$0$12910$c3e8da3$5496439d@news.astraweb.com> <862693ca-42cf-4f5b-ac12-133e43e7606b@googlegroups.com> <878uclf3bt.fsf@elektro.pacujo.net> <555af171$0$12995$c3e8da3$5496439d@news.astraweb.com> <874mn9ezaw.fsf@elektro.pacujo.net> <mailman.124.1432025439.17265.python-list@python.org> <555b2fa9$0$12996$c3e8da3$5496439d@news.astraweb.com>
Date: Tue, 19 May 2015 23:24:47 +1000
Subject: Re: Slices time complexity
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.134.1432041891.17265.python-list@python.org>
Lines: 53
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:90849

On Tue, May 19, 2015 at 10:42 PM, Steven D'Aprano
<steve+comp.lang.python@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@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