Nested function scope problem

[Antoon Pardon]

On 2006-08-01, danielx <danielwong at berkeley.edu> wrote:
> Gerhard Fiedler wrote:
>> On 2006-07-30 09:54:14, Antoon Pardon wrote:
>>
>> > Aren't you looking too much at implementation details now?
>>
>> Possibly, but at this point I'm still trying to understand how Python does
>> these things, and what the useful abstraction level is for me. I also still
>> have very little experience how I'll put the things we've been discussing
>
> Sorry I've been away from this sub-thread for a while (even though I
> kinda started it :P). Yes, I'm also wondering what difference this big
> huge argument makes on how I logically follow Python.
>
> Personally, I find this metaphor in "Head First Java" from O'Reilly
> Press really helpful for both Python and Java. Before anyone sends me a
> letter bomb that says "Python != Java", let me say this: have phun :P.
>
> Anyway, the metaphor goes something like this: variables (for objects,
> not primitives) are like cups (just wait, it gets better). You can put
> a remote control IN a cup. The remote control controls a "real" object
> on the heap (ie, the data for the object is there).
>
> Unfortunately, some of the effect of the metaphor is lost because I
> cannot reporduce the very nice illustrations which came in the book :P.
>
> Other than the fact that you declare variables in Java (going down
> another letter-bomb-laden slippery slope), which means they stick
> around even when they have no "remote controls", I pretty much think of
> Python variables the same way: each variable LOGICALLY contains a
> reference (ie, without regard to what the mechanics are) to some
> amorphous glob of data, sitting on the heap. Therefore, when I do an
> assignment, I am simply replacing the reference my variable is holding.
> According to the metaphor, we are replacing the remote control our cup
> is holding.
>
> If an object is no longer visible (because all the references have
> disappeared), then it should get garbage collected eventually. But
> until the magical garbage-collecting angle of death makes is way
> through the heap, our orphaned objects are PHYSICALLY still there until
> they are forcefully evicted from memory. Logically, however, they were
> gone as soon as we lost sight of them.
>
> Java aside, My question is this: how will using this metaphor break the
> way I logically follow Python?

I don't think it will cause you problems. The confusion from explaining
Python variables in terms of C-like references comes from the fact that
in Python both assignment and argument passing are reference passings.

In code like the following:

  def foo(x):
      x = x + 1

  a = 0
  f(a)
  print a

A number of people expect to see 1 printed. They remember that x will
be a reference of a and so expect a to be incremented by 1 after the
call. They forget that the assigment to x will cause x to refer to
a different integer and not cause it to refer to the same "object"
whose value is increased.

An other problem is that people don't realise that an assignment
to a simple identifier in a function, has a declarative effect.
So (unless the identifier was declared global) from the moment
there is some line like: ident = ... in a function, all occurences
of ident in that function will refer to the local variable.

So this works:

  def foo():
    b = a

  a = 1
  foo()

This doesn't:

  def foo():
    b = a
    a = 2 * b + 1

  a = 1
  foo()

Even this doesn't:

  def foo():
    if False:
      a = 1
    else:
      b = a

  a = 1
  foo()

Yet seems to work (which I think is an error in the optimisation;
replacing 0 by [], () or None shouldn't make a difference but
it no longer works in those cases):

  def foo():
    if 0:
      a = 1
    else:
      b = a

  a = 1
  foo()


-- 
Antoon Pardon