Akira Li <4kir4...@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. -- https://mail.python.org/mailman/listinfo/python-list
