Path: csiph.com!news.swapon.de!news.roellig-ltd.de!open-news-network.org!border2.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'exist,': 0.07; 'works.': 0.07; 'ambiguity': 0.09; 'incorrect': 0.09; 'issue:': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'python': 0.10; 'variables': 0.15; '*a*': 0.16; '*a*,': 0.16; 'containers': 0.16; 'objects).': 0.16; 'pairs': 0.16; 'received:80.91.229.3': 0.16; 'received:plane.gmane.org': 0.16; 'subject:reference': 0.16; 'subject:versus': 0.16; 'drawing': 0.18; 'exists': 0.18; '(the': 0.22; 'ascii': 0.22; 'object.': 0.22; 'seems': 0.23; 'wrote': 0.23; 'references': 0.23; 'represents': 0.23; 'header:User- Agent:1': 0.26; "doesn't": 0.26; 'header:X-Complaints-To:1': 0.26; 'correct': 0.28; 'objects': 0.29; "i'm": 0.30; "i'd": 0.31; "can't": 0.32; 'received:comcast.net': 0.33; 'add': 0.34; 'lists': 0.34; 'list': 0.34; 'clear': 0.35; 'lists.': 0.35; 'something': 0.35; 'but': 0.36; 'there': 0.36; 'subject:" ': 0.36; 'to:addr :python-list': 0.36; 'subject:: ': 0.37; 'two': 0.37; 'method': 0.37; 'received:org': 0.37; 'names': 0.38; 'mean': 0.38; 'represent': 0.38; 'why': 0.39; 'sure': 0.39; 'does': 0.39; 'rather': 0.39; 'to:addr:python.org': 0.40; 'claim': 0.61; 'show': 0.62; 'complete': 0.63; 'circle': 0.66; 'here': 0.66; 'talking': 0.67; 'therefore': 0.67; 'picture': 0.70 X-Injected-Via-Gmane: http://gmane.org/ To: python-list@python.org From: Random832 Subject: Re: Terminology: "reference" versus "pointer" Date: Sun, 13 Sep 2015 15:04:16 -0400 References: <55F36B4C.9020007@gmail.com> <1442016698.95299.381478313.2487CA0E@webmail.messagingengine.com> <85mvws6z45.fsf_-_@benfinney.id.au> <85io7g6xy4.fsf@benfinney.id.au> <85egi46wng.fsf@benfinney.id.au> <1a1a1f6a-27ce-4c1b-807a-43eabaa04abb@googlegroups.com> <04ca9d7c-d02b-4329-bd94-4d18d86b3edf@googlegroups.com> <87egi375wb.fsf@gmail.com> <87wpvu5h7f.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain X-Gmane-NNTP-Posting-Host: c-68-39-146-59.hsd1.in.comcast.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Cancel-Lock: sha1:N85cJXeTrWSAcxQRSX+FkFqeQgY= X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.20+ Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 35 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1442171066 news.xs4all.nl 23811 [2001:888:2000:d::a6]:43092 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:96519 Akira Li <4kir4.1i@gmail.com> writes: > I'm not sure what "parcel tags" model is but if you mean these > pictures[1] than it works in this case as well as any other (take *a*, > *b* nametags, put them on the corresponding balloons that represents > list objects). > > The only names left are *a* and *b* that refer to the corresponding > lists. There is no ambiguity there to put *a*, *b* nametags. But how do you make an a[0][0]/a[1][0] nametag to put on the "1" object? > Lists as any other containers contain references to other objects and > therefore "box and arrows" model provides _more details_ here[2,3] Right, but why not use the *same* model to represent *namespaces*? It seems like the "tags" model only exists to make the incorrect claim that python doesn't have variables (the boxes are variables). >> If the "parcel tags" model can't show it, then the "parcel tag" model >> clearly is not a correct and complete depiction of how Python actually >> works. >> (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. Everything you wrote here has the same issue: The "objects" you are talking about do not physically exist, but are simply the result of calling a method on the object. Therefore they do not *belong* on the diagram, and the diagram not showing them does not mean the diagram is not complete.