Nested function scope problem

[Slawomir Nowaczyk]

On Fri, 04 Aug 2006 10:10:45 -0300
Gerhard Fiedler <gelists at gmail.com> wrote:

#> On 2006-08-04 07:36:25, Slawomir Nowaczyk wrote:
#> 
#> > #> The address operator is probably for a C programmer the closest to
#> > #> what the id() function is to a Python programmer.
#> > 
#> > 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.

#> 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]

in Python. Of course, there is no object at memory address "5" (in C)
and no object in locals() named "5" (in Python). I agree there is a
difference between getting a segfault and getting an exception, but it
doesn't have much to do, IMHO, with what a variable is.

#> You can hardly claim that what gets printed is the "id" of the variable c.
#> (Well, you can claim, but few C programmers would follow you.)

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.

#> What would be analogous in Python to the textual representation of
#> the variable in C? The address operator in C in analog to the
#> textual representation in Python. The textual representation in C
#> is analog to ??? in Python?

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?

#> You may be talking about C pointers and call the locations they point to
#> "variables". 

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

#> That's a big difference; those are /not/ C variables.

I agree, the locations are not variables.

#> And they still are not the same.

OK, sure, there is a number of things that you can do to/with C variable
that you cannot to/with Python variable, so they are not "the same". I
just feel the differences are not large enough to warrant 

#> 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], 

#> Note that in standard C/C++ language, a and b in your example are variables
#> (in fact the only variables), not *a and *b. 

Agreed.

#> (three and four should have been declared as constants, to be
#> analogous to Python.)

True, but I didn't think it matters.

#> So the only variables in your example (a and b) don't really behave
#> according to your analogy.

Sorry, I do not follow.

#> What behaves somewhat like your analogy are *a and *b -- neither of
#> which are C/C++ variables. (Well, they are in your example, but
#> only because of sloppily applying your analogy. 

I never said *a is a variable.

#> And they are not in the general case: pointers don't care whether
#> they point to actual C/C++ variables, or to any other memory
#> location.)

I think I lost you, but Python names do? Does "a" in your *.py file
"care" whether they are bound to any object?

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?

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( Slawomir.Nowaczyk at cs.lth.se )

Science is a differential equation. Religion is a
boundary condition. -- Alan Turing