Path: csiph.com!news.swapon.de!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail
MIME-Version: 1.0
In-Reply-To: <87wpvu5h7f.fsf@gmail.com>
References: <c3363$547e74fe$5419aafe$24179@news.ziggo.nl> <14afe27e-0bd5-410f-8e64-0f31d496ebf2@googlegroups.com> <b695e$55f34cad$d47876e2$41259@news.ziggo.nl> <55F36B4C.9020007@gmail.com> <1442016698.95299.381478313.2487CA0E@webmail.messagingengine.com> <mt04ao$ite$1@ger.gmane.org> <m2zj0ss2md.fsf@fastmail.com> <85mvws6z45.fsf_-_@benfinney.id.au> <m2k2rws0yr.fsf@fastmail.com> <85io7g6xy4.fsf@benfinney.id.au> <m2egi4rzz5.fsf@fastmail.com> <85egi46wng.fsf@benfinney.id.au> <m2zj0sqjl8.fsf@fastmail.com> <mailman.419.1442039210.8327.python-list@python.org> <d55daf4b-b7c2-41fb-8010-76d6d65eb6b8@googlegroups.com> <mailman.425.1442068881.8327.python-list@python.org> <1a1a1f6a-27ce-4c1b-807a-43eabaa04abb@googlegroups.com> <mailman.435.1442080562.8327.python-list@python.org> <04ca9d7c-d02b-4329-bd94-4d18d86b3edf@googlegroups.com> <87egi375wb.fsf@gmail.com> <m21te3qqeg.fsf@fastmail.com> <87wpvu5h7f.fsf@gmail.com>
Date: Mon, 14 Sep 2015 05:03:59 +1000
Subject: Re: Terminology: "reference" versus "pointer"
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.490.1442171042.8327.python-list@python.org>
Lines: 70
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:96518

On Mon, Sep 14, 2015 at 4:04 AM, Akira Li <4kir4.1i@gmail.com> wrote:
>> (If I were drawing a picture rather than ASCII I'd add something to make
>> it clear that the pairs shown are list objects Like, it's a circle with
>> the word "list" and two pointer-boxes inside it.)
>
> "correct and complete" is impossible in the general case for any model.
>
> Imagine what happens if numpy arrays are used instead of Python lists:
>
>   lst = [numpy.array([1, 2]) for _ in range(3)]
>   a = [lst[0], lst[0]]
>   b = [lst[1], lst[2]]
>
> Note: there could be no a[0][0], a[0][1], etc corresponding Python
> objects until you explicitly reference them in the code. If there are no
> Python objects then you can't draw any arrows and therefore "box and
> arrows" model is incomplete.
>
> Or consider this collections of all Unicode characters:
>
>   class U:
>      def __len__(self):
>          return sys.maxunicode + 1
>      def __getitem__(self, index):
>          if index < 0:
>              index += len(self)
>          if 0 <= index < len(self):
>              return chr(index)
>          raise IndexError(index)
>
>   u = U()
>   print(u[0x61]) # -> a
>
> In this example, it is even more clear that the corresponding items
> might not exist until they are explicitly referenced in a program.

What you've shown there is that it's perfectly possible to have an
abstract collection which generates objects as they're needed. In the
same way, you could define an infinite range object, which effectively
has all positive odd numbers in it:

class Odd:
    def __getitem__(self, index):
        if index >= 0: return index * 2 + 1
        raise IndexError(index)

Obviously it can't have objects representing every positive odd
number, because that's an infinite set. If you want to think of this
as containing all of those integers, sure, but now we're getting into
functional programming styles and ways of representing infinity in
finite RAM, and some things will look a bit different.

However, none of this has anything to do with Python's object model.
The expression "index * 2 + 1" results in the creation of new integer
objects as required, rather than simply retrieving them from some
containment list. The boxes-and-arrows stuff is all about pre-existing
objects; if I construct one list from another, I expect all the
references to be the same, but if I construct two Odd() objects, they
don't have to be:

>>> o1 = Odd(); x1 = o1[12345]
>>> o2 = Odd(); x2 = o2[12345]
>>> x1 is x2
False

Even though every Odd() must, by definition, contain the exact same
integers, it doesn't contain the same objects - it doesn't contain any
objects.

ChrisA