On Fri, 04 Aug 2006 10:10:45 -0300
Gerhard Fiedler <[EMAIL PROTECTED]> 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
( [EMAIL PROTECTED] )
Science is a differential equation. Religion is a
boundary condition. -- Alan Turing
--
http://mail.python.org/mailman/listinfo/python-list
