Nested function scope problem

[Gerhard Fiedler]

On 2006-08-04 11:41:03, Slawomir Nowaczyk wrote:

> #> > I disagree. At least in my understanding, which, up to now, was
> #> > perfectly enough to explain everything about how Python variables
> #> > behave:
> #> > 
> #> > The address operator in C is what textual representation (i.e. what
> #> > you type, like "a") is in Python. Equivalent of id() is a dereference
> #> > operator.
> #> 
> #> But then you are not talking about C variables.
> 
> I am. The fact that Python variables behave like C pointers isn't
> overly relevant. A pointer is perfectly good C variable to me.

Let me try to make myself clear... Using your example, we have int*a. a is
a pointer to int. a is a C variable. *a is treated as an int; it may be a C
variable (of type int or not), but it often (maybe even more often than
not) is /not/ a C variable. When you request memory from the heap, you
don't get a C variable from the heap, you get a requested number of bytes.
This is not a C variable, it's only memory that gets written to using a
pointer.

You can say that in the context of your application logic, that is an
application variable. But it is not a C language variable.

The pointer itself (a) is of course a C variable. But you're not basing
your analogy on C pointer variables (a), you are basing it on whatever C
pointer variables point to (*a), which is in the general case not a C
variable (even though it can be one).

To better understand what I'm talking about, try to make a consistent
analogy. One side Python terms, on the other side the analogous C terms. 

You said previously:
>>> The address operator in C is what textual representation (i.e. what you
>>> type, like "a") is in Python. Equivalent of id() is a dereference
>>> operator.

Python === C
Textual representation a === Address operator (&a)
id(a) === Dereference operator (*a)

I think I didn't quite translate what you meant, but you get the idea. I
don't think you can come up with a working analogy. The differences are
just too many -- if you consider the C language on the right side, not a
custom application you developed in C.


> #> Using a normal C variable, this doesn't work:
> #> 
> #>   int c = 5;
> #>   printf( "id(c)=%x", *c );
> 
> Depends on what do you expect. The above is kind of equivalent to,
> say:
> 
> locals()[5]

No. You said that in your analogy, the "Equivalent of id() is a dereference
operator." I took a C variable (c) and applied to it what you say is the
equivalent of id() in C: the dereference operator.

Python:
  c = 5
  id(c)
C:
  int c = 5;
  printf( "id(c)=%x",*c);

If that is not correct according to your analogy, your analogy doesn't seem
to be worded in the way you mean it.


> That's possible. I wouldn't expect too many C programmers to have any
> notion of "id of a variable". I, for example, never thought about such
> thing before this thread.

I'm not sure how much C you did. But the address of a variable is a quite
important concept in C; something that "identifies" the variable. For
example, it is important to distinguish between static, heap and stack
variables, and one of the main differences is their address space and the
different ways these address spaces get managed.


> There is no "textual representation" of variables in C -- at least not at
> runtime. Why should there be? There is, after all, no equivalent to
> "eval('a=1')" so why would anybody care what was variable named?

I wasn't aware that you were talking only about runtime.


> Yes, I am talking about C pointers, but I call *them*, not what they
> point at, variables.

Not really. Try to make your analogy more explicit. Your analogy only works
(kind of) if you treat (in C) *a as the equivalent of a Python variable,
not a. 


> #> What is analog in Python (using your analogy) to the address 
> #> of the pointer variable in C (&a in your example)?
> 
> Well, how about x='a'? It allows you to do locals()[x], 

Now you're in a different example. It would be easier to follow if we stood
with one.


> #> So the only variables in your example (a and b) don't really behave
> #> according to your analogy.
> 
> Sorry, I do not follow.

You said that "the address operator [of a C variable] in C is what textual
representation is in Python." We agree that the pointer variable 'a' is a C
variable. So is '&a' in C the equivalent to 'id(a)' in Python? Your code
seemed to indicate that you meant 'a' to be the equivalent to 'id(a)' --
which is not consistent with your own definition of the equivalence. Check
out your example code; you didn't even include '&a'.

> I never said *a is a variable.

But you treated it as such in your example code.


> I just noticed that part of our disagreement comes from the fact that
> I am talking about C variables as they look at runtime, while you seem
> to also consider the source code to be relevant. Am I correct?

You're correct in that I considered the source. But that's not really
important. I could leave the C source and go to the C runtime. However,
then we don't really have anymore a C variable 'a', we only have a memory
location. That's probably one more inconsistency in the analogy. 

What I was mainly talking about is that the analogy as you worded it
doesn't seem to fit your example code. Which seems to indicate that it
doesn't work that well.

Gerhard