Nested function scope problem

Slawomir Nowaczyk slawomir.nowaczyk.847 at student.lu.se
Fri Aug 11 06:48:33 EDT 2006


On Wed, 09 Aug 2006 15:11:16 -0300
Gerhard Fiedler <gelists at gmail.com> wrote:

#> On 2006-08-09 07:54:21, Slawomir Nowaczyk wrote:
#> 
#> > 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.
#> 
#> Rests one question: what is the value of the variable? In Python, it would
#> be the result of "a". In C, it would be the result of ...? 

Hmmm, well, it should be value of a, but it clearly doesn't make much
sense. It seems like I got confused and was saying something else than
I was thinking.

So, indeed, you were right: this analogy is broken.

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

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

Housework can't kill you... but why take a chance?




More information about the Python-list mailing list