On Wed, 07 Jan 2009 03:49:02 +0000, Mark Wooding wrote: > Steven D'Aprano <ste...@remove.this.cybersource.com.au> wrote: > >> The only tricky thing is that items 1, 2 and 3 can be inside two >> different boxes at the same time. There's no obvious real world analogy >> to that without the boxes being nested. This ability for objects to be >> in two places at once (or even to be inside themselves!) is one of the >> few reasons why Python's use of references in the implementation needs >> to be mentioned. > > Ahh. So it /does/ need to be mentioned after all.
Only in the sense that the behaviour of *real world* objects don't entirely match the behaviour of Python objects. If you just accept that Python objects can be in two places at once, an unintuitive concept I accept but hardly difficult to grasp, then you don't need to mention references. (Of course, as a purely practical matter, the English language makes it difficult to avoid the word "reference" entirely. That's not my intention.) > But you're wrong: > it's not an implementation detail: it's an essential part of the > language semantics. Er, pardon me, but you yourself suggested that one could implement Python without using references to objects, "like keeping lists of clones, and magically updating all the clones whenever one us mutated. That may even be a valid implementation for a distributed Python". Like you suggested, it would be a seriously rotten model for standard Python, but it is possible. The language semantics specifies the *behaviour*, not the *mechanism* required to implement that behaviour. > A better analogy. The objects are scattered across the floor. No > object is contained in another. However, we have a plentiful supply of > bits of string, each of which is tied to a Teflon-covered paperweight at > one end and has a blob of Blu-Tack on the other. Instead of putting > something in a box directly, what we do is grab a piece of string, stick > the Blu-Tack to the thing, and put the paperweight in the box. Not a bad analogy. I like it. But it still fails. Why can't I stick the paperweight in the box *before* attaching the Blu- Tack to something else, and then forget about attaching the Blu-Tack? There's nothing in your model to prevent dangling pointers, except hand- waving "it doesn't work like that". I assume the string is made of Teflon, otherwise I could stick the Blu- Tack to another piece of string. By the same token, the floor needs to be Teflon too. Why can't I grab the string by the end with the Blu-Tack and follow it backwards to find out where the paperweight is? I obviously know how to handle the end, because according to your model I'm sticking it to other objects. I suppose maybe there's a robot that does that Blu-Tack sticking for me, I just point to the object and say "That one!" and it happens. The string itself is invisible except to radar, which the robot has, and I don't. That way I can't follow the string backwards to find out where the paperweight is. Hmmm. This model is getting awfully complicated: Teflon string, Teflon paperweights, Blu-Tack, *and* a robot (presumably Teflon as well), none of which are visible to Python code, as well as objects which are. > This > way, we can stick several bits of string to the same object and put the > paperweights in different boxes. Indeed, nothing stops us sticking two > bits of string to a box, and putting both paperweights inside that same > box. But fitting a box into itself twice requires origami skills that > frighten me. Ah, you've obviously never studied origami under Sensei Ping of the Clan of the Pointed Stick! > The Teflon stops the Blu-Tack from sticking to the paperweights, 'cos > you're not allowed to do that. > > There's a daemon who comes around periodically and cleans up the mess of > paperweights which aren't in boxes, and tidies away things which don't > have any string stuck to them any more, So there's a brief moment between creating the object and sticking the Blu-Tack on it when the daemon might take the object and the string away? No, I guess not, that's another thing I just have to take on faith... the daemon knows not to touch anything until the robot has finished with it. Can I tie two pieces of string together, stop the daemon from disposing of them? Apparently not. Objects in two places at one time isn't sounding that weird any more. I actually do like your model, despite poking holes in it. As a model for what CPython is doing under the hood, it pretty good. But it's not a model for what a Python programmer does when writing Python code. There's no action equivalent to "attach blob of Blu-Tack to object", no action equivalent to "put the paperweight in the box". The robot does that when you point to an object and say "put that inside the box". The programmer doesn't do these things, he says "put that object in the box" and the robot attaches the Blu-Tack and moves the paperweight. The strings and paperweights and Blu-Tack are invisible and intangible to the programmer, *and* they are an implementation detail: as you put it, we could implement Python using clones of objects magically kept in sync, no string required. -- Steven -- http://mail.python.org/mailman/listinfo/python-list