Nested function scope problem

[danielx]

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?

> here into (Python) practice. While not new to programming, I'm new to
> Python.
>
> > AFAIU, one can also build a C++ class hierarchy that with some small
> > limitations in used operators, would have semantics very similar to
> > Python. Would you argue that those using such a C++ class hierarchy would
> > no longer be using variables in C++?
>
> Probably not. But for me it's mostly about useful terminology, not
> necessarily "correct" terminology. In order to talk about correct
> terminology, we'd have to use a common definition of "variable". This is a
> term so widely used that I'm not sure there is a useful single definition
> of it; do you know one?

This is another thing I was thinking the entire time I was reading this
argument, but I didn't want someone to answer me in a condescending
tone on what exactly a variable IS. I guess I should attribute that
quote to Bill Clinton :P.

>
> In any case, the following doesn't seem to be implementation detail (and
> rather a part of the language), but it's not really understandable with a
> C++ concept of "variable":
>
> >>> a=3
> >>> id(a)
> 3368152
> >>> b=a
> >>> id(b)
> 3368152
> >>> b=4
> >>> id(b)
> 3368140
>
> You don't expect the "identity" of the variable b to change with a simple
> assignment from a C/C++ point of view. You also don't expect the "identity"
> of a and b to be the same after assigning one to the other. You can create
> C++ classes that behave like that (you can implement Python in C++ :), but
> that doesn't mean that you expect C++ language constructs to behave like
> that.

I'm really not comfortable with C, but I disagree. What would you say
about this program:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define tf(bool) (bool) ? "true" : "false"

const char * greeting = "hello world";

int main() {
  /* These mallocs don't really need to be hear for me to make my
     point, because as far as I know, what they return is garbage
     values anyway :P. I just put them there so my pointers are
     pointing to "real objects".*/
  char * string     = (char *) malloc(sizeof(char)*100);
  char * letterBomb = (char *) malloc(sizeof(char)*100);

  strcpy(string, greeting);
  strcpy(letterBomb, greeting);

  printf("are we equal? %s\n", tf(strcmp(string, letterBomb) == 0));
  printf("are we IDENTICAL? %s\n", tf(string == letterBomb));

  printf("sabotage...\n");
  letterBomb = string;
  printf("are we identical NOW? %s\n", tf(string==letterBomb));
}

> 
> Gerhard