nonlocal fails ?

[Peter J. Holzer]

On 2019-11-23 18:18:16 -0500, Richard Damon wrote:
> On 11/23/19 4:18 PM, Peter J. Holzer wrote:
> > On 2019-11-14 20:29:01 -0500, Dennis Lee Bieber wrote:
> >> 	Instead, at a simple level (a common description invokes "Post-It"
> >> notes)
> >>
> >> 		x = y
> >>
> >> means /find/ the object (somewhere in memory) that has a note "y" stuck to
> >> it. Without moving the "y" note, attach an "x" note to that same object.
> >> The object now has two names bound to it. If the "x" note used to be
> >> attached to an object, the old object no longer has that name -- and if the
> >> object has NO names attached, it is garbage collected.
> > Frankly, I find that model very unsatisfying.
[... reasons elided ...]
> > It's much simpler to talk about references or pointers or whatever you
> > want to call them. You can nicely visualize them with arrows (or pieces
> > of string, if you want, but arrows have the advantage of having a
> > direction) and it describes directly and without any mental gymnastics
> > what is going on (on a conceptual level - actual implementations might
> > be somewhat different, as long as they behave the same).
> >
> 
> A post-it note analogy is a very good description to allow a
> non-technical person to understand how it works.

It may allow a non-technical person to understand how it doesn't work. I
doubt this is very useful.


> Yes, as presented, it doesn't handle the concept of scope of variables,
> but that starts to get into more complexity than you might want for a
> simple model,

Yeah, that's exactly the problem. In an attempt to avoid being
"technical", it becomes needlessly complex. There seems to be a
wide-spread notion that goes something like this: This is how it really
works, therefore it is technical, and non-technical people don't
understand technical stuff. Therefore we must make up another
explanation. It will be more complicated and it will be wrong, but
because it is wrong it is non-technical, therefore non-technical people
will understand it.


> To a non-techie, a 'Pointer' is either a breed of dog or an arrow
> pointing in a general direction.

Ok, I apparently wasn't thinking straight yesterday. The real world
analogy is of course the address. Everybody knows what an address is
(and non-technical people won't have all that cognitive baggage either
which can lead programmers down endless rabbit holes). Adresses work
slightly differently in different countries (and sometimes even
different communities in the same country), but the differences won't
matter here. Let's just assume the street/house number system as it is
common in many western countries (if you are Japanese, think of blocks
and buildings instead).

So our objects live in houses on a street. When an object is created it
just plops into existence in an empty house (And they never leave their
house until they die, so the poor things are a pretty lonely bunch).

You don't tack post-it notes to the house-doors. Instead you have a
notebook[1] (or rather a bunch of them). So when you write something like

 1  x = "spam"
 2  y = "eggs"
 3  z = x + y
 4  Ω = z
 5  x = "ham"

what happens is this: 
 1  You create a new object with the value "spam": Let's say this is now
    in Basil Street 42
    You write into your notebook: "x: Basil Street 42"
 2  You create a new object with the value "eggs" in Basil Street 3
    You write into your notebook: "y: Basil Street 3"
 3  You look into your notebook for the notes "x" and "y", find the
    adresses "Basil Street 42" and "Basil Street 3" there, go to those
    addresses to ask the objects for their values, create a new combined
    object from them ("spameggs"), put it into a free house (Basil
    Street 23) and write that into your notebook: "z: Basil Street 23".
    (Oof, that was quite a mouthful for such a short line)
 4  You look up the address of "z" in your notebook and copy it into the
    entry for Ω: "Ω: Basil Street 23".
 5  You create yet another object ("ham") in Basil Street 52.
    You cross out your entry for "x" and write a new entry "x: Basil
    Street 52"
    (At this point there is no entry for Basil Street 42 in your
    notebook any more. Eventually the object at that house will notice
    that nobody loves it any more and die out of desparation)

This is quite close to what really happens, it generalizes nicely (e.g,
if you call a function, you just hand it a new notebook with just the
parameters filled in; An object (e.g. a tuple or a dict) may itself
possess a notebook; etc.) and it doesn't use any terms (except object)
that the "non-technical person" won't be familiar with.


> The key is that you are showing something fundamentally different than a
> box to hold a value. If you show names as boxes with arrows in them,
> someone is going to ask how to get one name point to another name (re
> the discussion about is it call by value or call by reference)

Which is a legitimate question. The answer is that Python's inventors
thought that it would be useful to make two kinds of boxes and arrows
can only originate on one kind and end at the other kind. You might get
a very similar question for post-its: Why can't I put a post-it on
another post-it? I can in real-life. (And of course the notebook
metaphor doesn't avoid this either: Why can't I write "Notebook 3, entry
foo" instead of a street address? Or draw a picture of a man-eating
rabbit? Any metaphor breaks down at some point)

        hp

[1] Thanks, Chris. The notebook is the perfect companion to the address
    metaphor.

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp at hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20191124/9f736ad2/attachment.sig>