Nested function scope problem

[danielx]

Gerhard Fiedler wrote:
> On 2006-08-05 09:30:59, Antoon Pardon wrote:
>
> >> But this means that C variables are not analog to Python variables,
> >> [...]
> >
> > Yes they are.
>
> Nobody so far has been able to create a simple table with analog operations
> Python vs C that operates on C /variables/ (not dereferenced pointers) and
> makes any sense. (Similar to the one Dennis just posted.)

At least for me, the point is that Python variables are precisely
analogous to C pointers (single star-ed); furthermore, there is nothing
analogous to C "primitives" (ie, C int, float, etc.); and the are no
references to references, only references to heap data.

I have two ways of explaining this. The first uses alot of word
chopping, making it rather long winded. The second relies on the notion
of a "homomorphism" used in abstract algebra. You may be able to follow
along even if you don't already know what a homomorphism is, but that
explanation will most likely benefit people who already do.

explanation attempt 1:

When I say things like "num1 is 'holding' a long", I am being quite
loose with the word "holding". Literally, I would say "the variable is
holding a reference". But references are the only thing Python
variables can hold; therefore, our loosely worded phrase can
unambiguously taken to mean that the reference "held" by num1 points to
a some "long struct".

This loose way of saying things tends to imply that the reference IS
the long itself (even though we have to follow the reference to reach
the actual data). From this, we can easily derive a notion of
"identity" in Python: two things are identical if they are the same
address (remember, all "things" are references). This make sense
because if we have "list1 is list2", then changes to list1 are also
seen in list2

comment: Unfortunately, I had to switch examples in the second
paragraph, since long is an immutable type. On the plus side, this
illustrates the deep consequences of immutable data types in Python.

explanation attempt 2 (me being a pretentioius ass):

I claim that there is some structure preserving function, a
homomorphism, which goes from Python variables to C variables when we
are working with the '+' operator in Python and the
"AllocateAndConsInteger( *dot + *dot )" operator in C.

To illustrate what the AllocateAndConsInteger function does, the
following are supposed to be analogous:

Python:
## initialize aPy and bPy
aPy = 1; bPy =2
xPy = aPy+bPy  # < --OPERATE

~

C:
/* declarations: annoying, but necessary */
int * aC, *bC, *xC;
/* initialize a and b */
aC = (int *) malloc(sizeof(int));
bC = (int *) malloc(sizeof(int));
*aC = 1; *bC = 2;
xC = AllocateAndConsInteger( *a + *b )  /* <-- OPERATE */

I think you can imagine a function f where the following (always)
holds:

f(aPy) == aC and f(bPy) == bC and f(xPy) = xC

Then f is a homomorphism...

Earlier, I described the above as "reasoning". Don't take that too
literally ;).

...

All of what I have been saying has been an attempt at getting across
what I had hoped to acomplish with my remote-in-cup analogy.
Unfortunately, it's very hard to do the analogy real justice without
good illustrations, which you will find in "Head First Java". It's
really a fun book...

>
> Just do it (I mean state a few operations on/with variables in either
> language, and what the analog operation in the other language is), and I
> may be a convert :)
>
>
> >> [...] C dereferenced pointers are.
> >
> > No they are not. a = b in Python translates to: a = b in C. It doesn't
> > translate to *a = *b in C.
>
> Hold this thought for a little while...
>
> > It is true that a = b + c in Python doesn't translate to a = b + c in
> > C, but since this really is a shortcut of a = b.__add__(c) there
> > is nothing wrong with tranlating it into something like:
> > a = IntPlus(b, c) for C, where the IntPlus will provide a new pointer
> > that points to the sum [...]
>
> Did you hold that thought? Now IntPlus() returns a "new pointer", which
> means that c is a pointer variable, not a value variable. Didn't you write
> above that it wasn't a pointer?
>
> > or we could provide the necessary structures so that we could translate
> > is as: a = b->__add__(c)
>
> Which of course again requires b to be a pointer. You seem not to be clear
> whether you want to create a C analogy (to Python variables) of C variables
> (as you stated above) or of C dereferenced pointers (as your code examples
> show).
>
> > [...] then there is something in C deserving the term variable which
> > behaves like variables do in Python.
>
> ?? There /is/ something in C called a variable. And there is something in
> Python (at least commonly) called variable. But IMO they don't behave in a
> similar way. (It is obviously possible to create something in C that
> behaves like a Python variable, but that's then not a C variable. It's a
> more complex C construct.)
> 
> Gerhard