why cannot assign to function call

[Mark Wooding]

Steven D'Aprano <steven at REMOVE.THIS.cybersource.com.au> wrote:

> 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.

To my mind, explaining that objects can actually be in two (or three, or
any unbounded number) of places at once, stashed inside each other to an
arbitrary degree -- that looks like the excuses of someone who's been
caught in a lie.  Maybe it was a useful lie-to-children, meant to avoid
explaining the full details in advance, but the time comes to put away
childish things, and learn the truth.  (I can't believe I just quoted
Paul.  I feel all dirty.)

> 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.

Yes, there's an isomorphism between the two, so technically either could
be used as a model to explain the behaviour of Python.  But, to my mind
at least, the idea of references (or sticky bits of string) is the
simpler -- it doesn't involve doing anything`magically' -- so Occam
suggests that it's superior.  I'm sure, if I tried, I could come with an
even more absurd model, or express it in more complicated ways, but the
power of a model lies in its combination of simplicity and explanatory
power.

The `they're just objects' model is very simple, but gets tied up in
knots explaining things.  The `it's all references' model is only a
little more complicated, but explains everything.

It might be -- and I don't know, because I'm not an educator -- that the
`they're just objects' model hits a local maximum in the tradeoff
between simplicity and explanation that's sufficiently high that it's
useful for teaching beginners.  It's hard to expose this simple model's
weaknesses without assignment (or messing with `is' or `id');
unfortunately, it's very easy to explose them once you do have
assignment (or any kind of mutable state).  And Python's purely
functional subset is rarely used exclusively in nontrivial programs.  So
I'm sceptical that this particular lie-to-children doesn't cause more
harm than good.

> 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".

Perils of posting at half past three in the morning, I'm afraid.  I
seemed to have hit a creative streak, but my clarity of thinking was
definitely impaired.

You are only allowed to handle paperweights.  A robot does the rest.
Some of the objects might give you splinters or paper cuts.  The robot
is concerned about your safety and won't let you go near them.  There's
a wall between you and the playpen, with a catflap in it.  The robot
will fit through the catflap but you're too big.

(For advanced users only: there might be a secret hatch which lets you
into the main arena where the robot works, via a storeroom containing a
surprising quantity of handy power tools, heavy weaponry, and
explosives, but oddly lacking in safety goggles.  You can build some
truly marvellous things by sneaking through here, and persuade the robot
to do things it wouldn't usually by threatening it at gunpoint, but you
can also blow yourself up.)

You tell the robot what you want him to do by handing him paperweights.
He doesn't take the paperweights away with him, but instead hooks onto
the string so that he can follow it to the other end.  He's quite good
at following even tangled strings, and at finding paperweights in boxes
and hooking onto their strings too.  The robot will stick new strings
onto objects at your request and hand you the paperweights.

> 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.

You could do, if you were actually given a loose piece of string.  But
you aren't, so that's OK.  I was wrong that the paperweights needed to
be Teflon.

> 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? 

Because you're never at that end.  And the robot just won't do that.

(The daemon in the MIT Scheme environment /can/ do this for you.  It
uses a feature called `wabbit hunting'.  You set up a `Fudd thunk'
describing which objects you want it to find the paperweights of, and
set the thing to `wabbit season'.  The daemon will track down the
`wabbits' -- boxes holding those paperweights -- that you asked for and
returns them.  When you want it to stop doing this, you return to `duck
season'.  Yes, it's very silly.)

> 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.

Wow.  I didn't actually read this far before hitting `follow-up', but
you anticipated the robot.  Well done.  But, no, actually nothing needs
to be made of Teflon, and I was just tired.

> Ah, you've obviously never studied origami under Sensei Ping of the
> Clan of the Pointed Stick!

Apparently not.  My origami skills are, alas, weak.

> 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. 

The daemon knows not to interfere with the robot, and the robot knows to
do everything in the right order.  But the daemon is an optional part of
the model, so we can just ignore him until we're ready to deal with him.

The daemon's name is Maxwell, by the way.  Say hello, Maxwell.

> Can I tie two pieces of string together, stop the daemon from disposing 
> of them? Apparently not.

No, but you can confuse him for a little while by building box-
paperweight-string-box-... cycles.  Eventually he cottons on to what
you've done, though.

> 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".

No, indeed.  Python is a language for talking about paperweights.  And
it's because of the paperweights that the duck-typing works: all the
paperweights are the same shape and size, so they're physically
interchangeable.

> 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.

Yup!

> 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.

You could try to explain Python in terms of paperweights only, but since
they all look identical, it's hard to see why interesting behaviour
emerges without explaining about the world on the side of the strings.

Of course, the paperweights-and-string-(and-robot-and-catflap-(and-
storeroom-cum-arms-cache)) model explains it all, and doesn't leave you
having to learn Sensei Ping's arcane origami skills.

If you're actually /in/ the arena with the objects, armed with the
ability to fold a box so strangely that you can store it in three other
boxes and itself, how come you never make a catastrophic mistake?

My answer is that the robot doesn't make mistakes often, and the worst
you can do to yourself is get in a bit of a tangle with those bits of
string.  If you're really cunning, you might manage to persuade the
robot to fetch a hand-grenade from the storeroom and blow itself up, but
there'll be a new version of the robot available later which won't fall
for that trick.

-- [mdw]