Nested function scope problem

Wed Aug 9 06:54:21 EDT 2006

On Fri, 04 Aug 2006 14:09:15 -0300
Gerhard Fiedler <gelists at gmail.com> 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.

I agree.

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

I am not saying that. All the time I am talking about "C variable" I
mean "a", not "*a".

#> 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).

I beg to differ. I *am* basing my analogy on the fact that "a" is a
variable.

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

Nope. Equivalence table can look like this:

       Python                             C
variable:                a          variable:              a
textual representation: "a"         address operator:     &a
id of object:           id(a)       dereference operator: *a

Also, notice, that "id(a)" does not really "identify" a variable. It
only identifies *object* which is bound to this variable. Both in
Python and in C.

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

I do think this is a working analogy.

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

OK, I was sloppy... id( locals()[5] ) doesn't work either.

You take a C variable which doesn't point at any object. This can be
seen as taking id() of an unbound variable in Python. Of course, there
*is* a difference: you get an exception in Python, a segfault in C.
But I do not see how that justifies to claim that Python has no
variables.

#> Python:
#>   c = 5
#>   id(c)
#> C:
#>   int c = 5;
#>   printf( "id(c)=%x",*c);
#> 
#> If that is not correct according to your analogy, 

It is not. "int c=5" is not equivalent, in my analogy, to "c=5". In
fact, "int c=5" has no real equivalent in Python: you cannot have a
Python name (i.e. variable) have a *direct value* of 5: it has to be
bound to some object.

#> your analogy doesn't seem to be worded in the way you mean it.

Possibly. Does the table above explain my idea better?

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

Sure. I do not know how is this relevant to current discussion,
though. Of course "address of variable" is important in C. Just as
textual representation is important in Python (allowing you to do
stuff like "eval('a+1')".

Obviously, *if* you consider address of a C variable to be equivalent
to Python id(), *then* C variables are not equivalent to Python
variables.

This, however, is not sufficient to claim that "C variables are not
equivalent to Python variables". The id() may correspond to some other
C concept -- I give you one example that works for me. You need to
show that there exists none.

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

No. In fact, it *doesn't* work in that case.

I treat *a as Python _object_. I.e. this funny thing which can be
destroyed by a GC/reference counting when no longer needed.

It is definitely *not* a variable.

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

Yes.

#> So is '&a' in C the equivalent to 'id(a)' in Python?

No, *a is equivalent to id(a), &a is equivalent to "a".

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

No I did not. At least not intentionally.

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

I think it would be easier to talk this way... After all, "int a=1"
and "int b=1" are *exactly* equivalent in C, while "a=1" and "b=1" are
not quite as equivalent in Python (consider if next line of program
contains stuff like input() )

#> However, then we don't really have anymore a C variable 'a', we
#> only have a memory location. 

I tend to disagree -- I would say that the term "variable" has meaning
also at runtime.

#> That's probably one more inconsistency in the analogy.

Not really, that's exactly what makes the analogy work.

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

Don't personify computers. They hate that.