Nested function scope problem

[Gerhard Fiedler]

On 2006-08-11 07:48:33, Slawomir Nowaczyk wrote:

> But let me try again, please (just one more time, if this doesn't work
> either I am willing to admit I do not see a simple analogy between
> Python and C variables :-)
> 
>        Python                             C
> variable:               a            variable:              a
> value of variable:      eval("a")    dereference operator: *a
> textual representation: "a"          address operator:     &a
> id of object:           id(a)        value of variable:     a
> 
> Thus, equivalent operations would be:
> 
>        Python                             C
> a = 1003                             a = &three  // (1)
> id(a)                                a
> b = 1004                             b = &four
> a == b          # False              *a == *b    // false
> id(a) == id(b)  # False              a == b      // false
> b = a                                b = a     
> a == b          # True               *a == *b    // true
> id(a) == id(b)  # True               a == b      // true
> a = 1001+1002                        a = MallocNewIntFromValue( one+two )
> a == b          # True               *a == *b    // true

Probably not True; b refers to the 1003 object, a refers to the 2003 
object. But that's just a minor "bug" in your selection of values :)  Your 
intention was probably to make a = 1001+2 in the line above.

> id(a) == id(b)  # False / True (2)   a == b      // false / true
> a = 1003+1004                        a = MallocNewIntFromValue( three+four )
> a == b          # False              *a == *b    // false
> id(a) == id(b)  # False              a == b      // false
> 
> (1) one, two, three and four are constants, something like "const int
>     one = 1". That is because there is no "literal int object" in C
>     - the thing you would write as "1" is likely not to actually
>     exist at runtime. And you cannot take an address of it.
> 
> (2) is actually True in CPython implementation for small integers, but
>     that's a minor detail. MallocNewIntFromValue might cache objects
>     as well.

I don't have a problem with that analogy. I guess we also agree that it has 
its limits (as all analogies have). However, with this analogy, a and b 
/must/ be pointer variables in C; the analogy does not work if a and b are 
not pointers. 

Which brings me back to my earlier statement: if it is at all possible to 
create a useful analogy between Python variables and C variables, it is 
between Python variables and C /pointers/. There is still no useful analogy 
between Python variables and general C variables (i.e. non-pointer 
variables). Note that non-pointer variables can contain objects, not only 
simple types. But they still are not analog.

Gerhard