why cannot assign to function call

[Steven D'Aprano]

On Wed, 07 Jan 2009 03:49:02 +0000, Mark Wooding wrote:

> Steven D'Aprano <steven at 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