Hello,
IIRC, I once saw an explanation how Python doesn't have "variables" in
the sense that, say, C does, and instead has bindings from names to
objects. Does anyone have a link?
Thanks,
Ami
41  2482 
none a écrit :
Hello,
IIRC, I once saw an explanation how Python doesn't have "variables"
in the sense that, say, C does, and instead has bindings from names to
objects. Does anyone have a link?
Thanks,
Ami
That's something I've often heard and I don't get it. Somehow I don't
understand how C variables are not like python bindings (the differences
being that C variables are statically typed and completely disappear at
run-time; are these differences important enough to warrant such a shift
in terminology ? (yes there are some other differences, but then the
question is asked in a context of pedagogy, where the audience is
introduced to the basics))
I mean : aren't C variables also bindings from names to objects ? Or what ?
Aurélien Campéas schrieb:
none a écrit :
> Hello,
IIRC, I once saw an explanation how Python doesn't have
"variables" in the sense that, say, C does, and instead has bindings
from names to objects. Does anyone have a link?
Thanks,
Ami
That's something I've often heard and I don't get it. Somehow I don't
understand how C variables are not like python bindings (the differences
being that C variables are statically typed and completely disappear at
run-time; are these differences important enough to warrant such a shift
in terminology ? (yes there are some other differences, but then the
question is asked in a context of pedagogy, where the audience is
introduced to the basics))
I mean : aren't C variables also bindings from names to objects ? Or what ?
There are cruicial differences. In C, you have names pointing to
physical memory locations - fixed locations, that is.
Thus you can do e.g.
some_struct a, b;
a = b = some_struct_value;
a.bar = 10;
b.bar = 20;
Now a.bar will be different from b.bar
This is totally different from python semantics, where
a = b = some_object
a.bar = 10
b.bar = 20
will result in both times the same object being manipulated.
So python variables are more equivalent to pointers in C.
Diez
Aurélien Campéas wrote:
none a écrit :
> Hello,
IIRC, I once saw an explanation how Python doesn't have
"variables" in the sense that, say, C does, and instead has bindings
from names to objects. Does anyone have a link?
Thanks,
Ami
That's something I've often heard and I don't get it. Somehow I don't
understand how C variables are not like python bindings (the differences
being that C variables are statically typed and completely disappear at
run-time; are these differences important enough to warrant such a shift
in terminology ? (yes there are some other differences, but then the
question is asked in a context of pedagogy, where the audience is
introduced to the basics))
I mean : aren't C variables also bindings from names to objects ? Or what ?
Thanks.
It's very possible you're right - I don't know. There seem to be some
differences however. To name a few:
1. A C variable exists regardless of whether you're storing something in
it. Not so for a python "variable" - so it's a bit really more like a
name for something that exists independently.
2. C variables (or C++ objects) completely disappear when out of scope,
but that's not necessarily true of Python objects.
3. C++ references have the semantics that if a = b, and you write a.c =
3, then b.c == 3. This is also true in Python. But then if a = b, and
then you write b = 5, then a is still bound to the original value of b,
so it's not exactly like a reference.
4. Etc.
So on the one hand, you're obviously right, and maybe there's no room
for a paradigm shift. OTOH, if the simplest explanation is "it's like a
C/C++ variable/reference/pointer except for 1, 2, 3, 4,...", then maybe
it is different. I just don't know, hence my question.
In article <47********@news.bezeqint.net>, none <""atavory\"@(none)"wrote:
>
IIRC, I once saw an explanation how Python doesn't have "variables" in
the sense that, say, C does, and instead has bindings from names to
objects. Does anyone have a link?
http://starship.python.net/crew/mwh/...jectthink.html
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/
"Typing is cheap. Thinking is expensive." --Roy Smith
"Aurélien Campéas" <sp***********************@free.frwrote in message
news:47***********************@news.free.fr...
I mean : aren't C variables also bindings from names to objects ? Or what
?
No, they're not.
In C, when you execute
x = y;
you cause x to become a copy of y. In Python, when you execute
x = y
you cause x and y to be two different names for the same object.
It is difficult to distinguish these cases unless the objects in question
are mutable, so consider this C example:
struct {int a, b;} x = {3, 4}, y = x;
x.a = 42
printf ("%d, %d\n", y.a, y.b);
and the following apparently analogous Python example:
x = [3, 4]
y = x
x[0] = 42
print y
Try them both and see how they behave.
Aahz wrote:
In article <47********@news.bezeqint.net>, none <""atavory\"@(none)"wrote:
> IIRC, I once saw an explanation how Python doesn't have "variables" in
the sense that, say, C does, and instead has bindings from names to
objects. Does anyone have a link?
http://starship.python.net/crew/mwh/...jectthink.html
Thanks!
Aurélien Campéas wrote:
I mean : aren't C variables also bindings from names to objects ?
No, C variables are aliases for memory addresses.
Regards,
Björn
--
BOFH excuse #390:
Increased sunspot activity.
none <""atavory\"@(none)"writes:
IIRC, I once saw an explanation how Python doesn't have "variables"
in the sense that, say, C does, and instead has bindings from names
to objects. Does anyone have a link?
In addition to the good answers you've had already, I highly recommend
David Goodger's "Code like a Pythonista" page
<URL:http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html>,
which contains a very good "cardboard boxes versus paper tags" analogy
of the topic you're asking about.
--
\ "My roommate got a pet elephant. Then it got lost. It's in the |
`\ apartment somewhere." -- Steven Wright |
_o__) |
Ben Finney
Ben Finney wrote:
none <""atavory\"@(none)"writes:
>IIRC, I once saw an explanation how Python doesn't have "variables"
in the sense that, say, C does, and instead has bindings from names
to objects. Does anyone have a link?
In addition to the good answers you've had already, I highly recommend
David Goodger's "Code like a Pythonista" page
<URL:http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html>,
which contains a very good "cardboard boxes versus paper tags" analogy
of the topic you're asking about.
Thanks!
none wrote:
IIRC, I once saw an explanation how Python doesn't have "variables"
in the sense that, say, C does, and instead has bindings from names to
objects.
If you're talking to C programmers, just tell them that
Python variables always contain pointers. That should
give them the right mental model to build on.
--
Greg
greg <gr**@cosc.canterbury.ac.nzwrites:
none wrote:
> IIRC, I once saw an explanation how Python doesn't have
"variables" in the sense that, say, C does, and instead has bindings
from names to objects.
If you're talking to C programmers, just tell them that Python
variables always contain pointers. That should give them the right
mental model to build on.
That is a convenient shortcut when it works, but in my experience it
tends to confuse the issue. The reason is that one of the main uses
of pointers in C is implementing pass-by-reference. A C programmer
told that Python variables internally hold pointers expects this code:
def func(a):
a = 10
....
func(x)
to change the value of x.
Hrvoje Niksic wrote:
greg <gr**@cosc.canterbury.ac.nzwrites:
none wrote:
IIRC, I once saw an explanation how Python doesn't have
"variables" in the sense that, say, C does, and instead has bindings
from names to objects.
IMHO, this is nonsense. All that variables are (in any language) are
"bindings" for names. Pretending python does anything novel with
regard to "variables" is confusing and, ultimately, simply results in
a redefinition of terms programmers are already familiar with. I
mean, it's kind of like saying my computer is not a computer but is
actually a device that follows input directions. Of course that
description may be true (and I may even use it to explain to students
*what* a computer is), but it is no less a computer for it.
If you're talking to C programmers, just tell them that Python
variables always contain pointers. That should give them the right
mental model to build on.
That is a convenient shortcut when it works, but in my experience it
tends to confuse the issue. The reason is that one of the main uses
of pointers in C is implementing pass-by-reference. A C programmer
told that Python variables internally hold pointers expects this code:
I think most C programmers are smart enough to figure out the supposed
differences, with only a little additional explanation on the part of
the instructor. Python's "variable model" is practically identical to
that of Java, after all, and I don't recall any discussion of
cataclysmic proportions over the differences between C "pointers" and
Java "references". There are "differences" (or more accurately
"points of emphasis"), but of the sort that take a paragraph or two of
explanation/clarification -- not a completely new model.
def func(a):
a = 10
...
func(x)
to change the value of x.
Depends on how you implement the C "equivalent". The most direct
translation, IMHO, is the following:
void func(int *a){
a = 10; //Of course this is nonsense, but it illustrates the
point. Just because "a" is a pointer
//does not mean that "a" is not rebound when it is
assigned to. Oh wait! Did I use
//the word "rebound" when talking about a *C*
variable? ;-)
//*a = 10; //I'm guessing this is what *you* had in mind, but it
is very different
}
int main(int argc, char **argv){
int x = 5;
func(&x);
printf("x is: %i\n", x);
return 0;
}
Which prints:
x is: 5
In this case, both the C and Python code have the same result.
--Nathan Davis
On Nov 26, 2007 1:21 PM, da*********@gmail.com <da*********@gmail.comwrote:
Hrvoje Niksic wrote:
greg <gr**@cosc.canterbury.ac.nzwrites:
none wrote:
> IIRC, I once saw an explanation how Python doesn't have
>"variables" in the sense that, say, C does, and instead has bindings
>from names to objects.
>
IMHO, this is nonsense. All that variables are (in any language) are
"bindings" for names. Pretending python does anything novel with
regard to "variables" is confusing and, ultimately, simply results in
a redefinition of terms programmers are already familiar with. I
mean, it's kind of like saying my computer is not a computer but is
actually a device that follows input directions. Of course that
description may be true (and I may even use it to explain to students
*what* a computer is), but it is no less a computer for it.
Long real-life experience that people with previous programming
experience, especially C programmers, have a great deal of trouble
with this concept. Python "variables" do not work the way they do in
other languages, where variables are compile-time bindings for memory
locations. Even Java references aren't the same (there's no such thing
as a null reference in Python, for example).
If you're talking to C programmers, just tell them that Python
variables always contain pointers. That should give them the right
mental model to build on.
That is a convenient shortcut when it works, but in my experience it
tends to confuse the issue. The reason is that one of the main uses
of pointers in C is implementing pass-by-reference. A C programmer
told that Python variables internally hold pointers expects this code:
I think most C programmers are smart enough to figure out the supposed
differences, with only a little additional explanation on the part of
the instructor. Python's "variable model" is practically identical to
that of Java, after all, and I don't recall any discussion of
cataclysmic proportions over the differences between C "pointers" and
Java "references". There are "differences" (or more accurately
"points of emphasis"), but of the sort that take a paragraph or two of
explanation/clarification -- not a completely new model.
C programmers, when told that Python works like this almost *always*
get this wrong, because they want to pretend that Python is C-like
pass by reference and it isn't.
The very first thing they want to do is to get at "the pointer"
underneath the object so they can simulate C style pass by reference
with ints. It takes a lot of bandwidth (both mental and electronic)
before they get that there is no underlying pointer and they can't do
this.
The second thing they want to do is to intercept rebinding actions,
like you might do in C++ with operator overloads. If you explain it to
them in these terms, it is not clear (and will not be, until you use
other terms) that rebinding a name (assignment) and mutating an object
are fundamentally different operations.
I see these questions on a daily basis in #python and somewhat less
frequently in c.l.p. Your assertion that C programmers will "just get
it" if it's explained in those terms is simply not borne out by real
world results.
One thing that C programmers *do* get, at least the smarter ones, is
explaining it in terms of the actual implementation - that there are
PyObject structs that are not exposed, that they are refcounted, and
that name/object bindings are entries in various hash tables. Saying
"it's just like a pointer" isn't generally sufficient, because it's
not like a pointer, and it gives them totally the wrong model to work
with.
def func(a):
a = 10
...
func(x)
to change the value of x.
Depends on how you implement the C "equivalent". The most direct
translation, IMHO, is the following:
void func(int *a){
a = 10; //Of course this is nonsense, but it illustrates the
point. Just because "a" is a pointer
//does not mean that "a" is not rebound when it is
assigned to. Oh wait! Did I use
//the word "rebound" when talking about a *C*
variable? ;-)
//*a = 10; //I'm guessing this is what *you* had in mind, but it
is very different
}
The very first thing a C programmer will want to do when seeing this
snippet is ask how to do the later operation in Python. If you tell
them they can't, they will then think of python variables as "like
pointers, except for special cases" which is wrong. If you use Python
semantics to explain it, in terms of names and bindings, they'll see
that it's not at all like pointers, that assignment operations are
totally consistent (assignment is name binding, not mutation) and that
immutable objects are immutable by virtue of not having mutating
methods, not because of compiler magic.
The only "special cases" which then need to be explained are augmented
assignment and object attribute assignment, which are easily (and
correctly) explained as being syntactic sugar for mutate + rebind and
a mutating method respectively.
On Nov 25, 10:36 pm, Ben Finney <bignose+hates-s...@benfinney.id.au>
wrote:
>
In addition to the good answers you've had already, I highly recommend
David Goodger's "Code like a Pythonista" page
<URL:http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html>,
which contains a very good "cardboard boxes versus paper tags" analogy
of the topic you're asking about.
or even Ben's own version of this, which I liked:
<URL: http://groups.google.com/group/comp....se_frm/thread/
56e7d62bf66a435c/ab62283cde9e4c63#ab62283cde9e4c63>
J^n
On Mon, 26 Nov 2007 21:37:19 +1300, greg wrote:
none wrote:
> IIRC, I once saw an explanation how Python doesn't have "variables"
in the sense that, say, C does, and instead has bindings from names to
objects.
If you're talking to C programmers, just tell them that Python variables
always contain pointers. That should give them the right mental model to
build on.
Until they wonder why this doesn't work.
x = 1 # x points to 1
y = x
assert x is y # confirm y points to the same memory location as x
x += 1
assert y == 2 # so naturally y should be incremented as well
--
Steven
Chris Mellon wrote:
On Nov 26, 2007 1:21 PM, da*********@gmail.com <da*********@gmail.comwrote:
Hrvoje Niksic wrote:
greg <gr**@cosc.canterbury.ac.nzwrites:
>
none wrote:
IIRC, I once saw an explanation how Python doesn't have
"variables" in the sense that, say, C does, and instead has bindings
from names to objects.
IMHO, this is nonsense. All that variables are (in any language) are
"bindings" for names. Pretending python does anything novel with
regard to "variables" is confusing and, ultimately, simply results in
a redefinition of terms programmers are already familiar with. I
mean, it's kind of like saying my computer is not a computer but is
actually a device that follows input directions. Of course that
description may be true (and I may even use it to explain to students
*what* a computer is), but it is no less a computer for it.
Long real-life experience that people with previous programming
experience, especially C programmers, have a great deal of trouble
with this concept. Python "variables" do not work the way they do in
other languages, where variables are compile-time bindings for memory
locations. Even Java references aren't the same (there's no such thing
as a null reference in Python, for example).
I myself learned C++ first, then transitioned to Java, then Python.
Once I got the hang of C++ pointers, I personally did not have any
significant difficulties with Java's references, and even less so with
Python's <whatever you want to call them>. Granted that's just my
experience, which doesn't mean others don't have that difficulty, but
that *is* my experience.
Also, to say that "there's no such thing as a null reference in
Python," is, IMHO, another example of nonesense. Null is a *concept*,
not a particular *value*, and simply means "there's no real value
here." The fact that Python's null is called "None" does not change
that. Furthermore, the fact that Python's designers were good enough
to create a "smarter" null than most languages have does not change
that. None is still a special value that is used to represent the
fact that there is "nothing here".
If you're talking to C programmers, just tell them that Python
variables always contain pointers. That should give them the right
mental model to build on.
>
That is a convenient shortcut when it works, but in my experience it
tends to confuse the issue. The reason is that one of the main uses
of pointers in C is implementing pass-by-reference. A C programmer
told that Python variables internally hold pointers expects this code:
>
I think most C programmers are smart enough to figure out the supposed
differences, with only a little additional explanation on the part of
the instructor. Python's "variable model" is practically identical to
that of Java, after all, and I don't recall any discussion of
cataclysmic proportions over the differences between C "pointers" and
Java "references". There are "differences" (or more accurately
"points of emphasis"), but of the sort that take a paragraph or two of
explanation/clarification -- not a completely new model.
C programmers, when told that Python works like this almost *always*
get this wrong, because they want to pretend that Python is C-like
pass by reference and it isn't.
Which is why you need the "points of emphasis"/"caveats". I never
claimed this is a slam-dunk.
The very first thing they want to do is to get at "the pointer"
underneath the object so they can simulate C style pass by reference
with ints. It takes a lot of bandwidth (both mental and electronic)
before they get that there is no underlying pointer and they can't do
this.
Well, Java calls them "references" instead of "pointers", which may
not be a bad idea if only to emphasize that there are, in fact,
differences. Java seems to have gotten away with explaining these
differences in a pretty concise manner. I don't see any reason why
Python can't do likewise.
The second thing they want to do is to intercept rebinding actions,
like you might do in C++ with operator overloads. If you explain it to
them in these terms, it is not clear (and will not be, until you use
other terms) that rebinding a name (assignment) and mutating an object
are fundamentally different operations.
I assume you are talking about overloading "operator =" in C++, but
that only works for non-pointers. How do you "intercept" rebinding of
a *pointer* in C/C++?
I see these questions on a daily basis in #python and somewhat less
frequently in c.l.p. Your assertion that C programmers will "just get
it" if it's explained in those terms is simply not borne out by real
world results.
Again, I never said C programmers will "just get it." That's why I
used the phrase "with only a little additional explanation." Maybe I
misinterpreted the original post, but my main point is simply that we
should call a spade a spade. Variables are variables whether they are
C pointers, Java references, or Python "name bindings. To say
otherwise just confuses the matter IMHO. There are differences, but
let's focus on the *differences* instead of re-naming things.
Sorry if I come off a little strong on a few points. Please keep in
mind that this is just my opinion of the matter.
--Nathan Davis
Hrvoje Niksic wrote:
A C programmer
told that Python variables internally hold pointers expects this code:
def func(a):
a = 10
...
func(x)
to change the value of x.
He shouldn't expect that, because that's not what the
equivalent code would do in C. To get that effect in C,
you would (among other things) have to write the
call as
func(&x)
which you can't do, because there is no & operator in
Python.
I would probably use the term "reference", and explain
it by saying that a reference is a pointer to an object.
Also that Python variables always hold references, never
objects; a reference always refers to an entire object,
never a part of an object or another variable; and that
assignment is always reference assignment and never
copies objects.
And illustrate everything with lots of drawings of
boxes and arrows. It's much easier to explain all these
things unambiguously with diagrams than with words
that may not mean the same thing to the listener that
they mean to you.
--
Greg
On 2007-11-26, da*********@gmail.com <da*********@gmail.comwrote:
Hrvoje Niksic wrote:
>greg <gr**@cosc.canterbury.ac.nzwrites:
none wrote:
IIRC, I once saw an explanation how Python doesn't have
"variables" in the sense that, say, C does, and instead has
bindings from names to objects.
IMHO, this is nonsense. All that variables are (in any
language) are "bindings" for names. Pretending python does
anything novel with regard to "variables" is confusing and,
ultimately, simply results in a redefinition of terms
programmers are already familiar with.
Someone who says Python identifiers aren't variables, as in C, is
thinking of C variables, which behave quite differently than
Python identifiers.
I mean, it's kind of like saying my computer is not a computer
but is actually a device that follows input directions. Of
course that description may be true (and I may even use it to
explain to students *what* a computer is), but it is no less a
computer for it.
Your analogy is begging the question. Noone is claiming that a
variable is not a variable. Python identifiers are variables in a
broad sense. But they aren't like C variables.
If you're talking to C programmers, just tell them that
Python variables always contain pointers. That should give
them the right mental model to build on.
That is a convenient shortcut when it works, but in my
experience it tends to confuse the issue. The reason is that
one of the main uses of pointers in C is implementing
pass-by-reference. A C programmer told that Python variables
internally hold pointers expects this code:
I think most C programmers are smart enough to figure out the
supposed differences, with only a little additional explanation
on the part of the instructor. Python's "variable model" is
practically identical to that of Java, after all, and I don't
recall any discussion of cataclysmic proportions over the
differences between C "pointers" and Java "references". There
are "differences" (or more accurately "points of emphasis"),
but of the sort that take a paragraph or two of
explanation/clarification -- not a completely new model.
There are more differences than similarities. Pointers are are a
low-level mechanism suitable for many purposes, referencing
values amongst them. Python identifiers are a high-level
machanism, suitable for only one purpose.
--
Neil Cerutti
On Nov 25, 5:31 pm, none <""atavory\"@(none)"wrote:
Aurélien Campéas wrote:
none a écrit :
Hello,
IIRC, I once saw an explanation how Python doesn't have
"variables" in the sense that, say, C does, and instead has bindings
from names to objects. Does anyone have a link?
Thanks,
Ami
That's something I've often heard and I don't get it. Somehow I don't
understand how C variables are not like python bindings (the differences
being that C variables are statically typed and completely disappear at
run-time; are these differences important enough to warrant such a shift
in terminology ? (yes there are some other differences, but then the
question is asked in a context of pedagogy, where the audience is
introduced to the basics))
I mean : aren't C variables also bindings from names to objects ? Or what ?
Thanks.
It's very possible you're right - I don't know. There seem to be some
differences however. To name a few:
1. A C variable exists regardless of whether you're storing something in
it. Not so for a python "variable" - so it's a bit really more like a
name for something that exists independently.
2. C variables (or C++ objects) completely disappear when out of scope,
but that's not necessarily true of Python objects.
3. C++ references have the semantics that if a = b, and you write a.c =
3, then b.c == 3. This is also true in Python. But then if a = b, and
then you write b = 5, then a is still bound to the original value of b,
so it's not exactly like a reference.
4. Etc.
So on the one hand, you're obviously right, and maybe there's no room
for a paradigm shift. OTOH, if the simplest explanation is "it's like a
C/C++ variable/reference/pointer except for 1, 2, 3, 4,...", then maybe
it is different. I just don't know, hence my question.
(If I say something wrong, please raise your hand)
For me, python variables are _exactly_ the same as reference counted
(or garbage collected) C++ pointers. It's just that the assignment
operator in python has distinctive semantics.
for example: the following code in python
a = 3
print a + 2
print len(a)
b = a
print id(a), id(b)
print a + b
a = 5
is similar to the following pseudo-code in C++
object *a, *b;
// a = 3
a = refnew<Int>(3);
// print a + 2
print(a->add(*refnew<Int>(2)));
// print len(a)
cout << len(*a) << '\n';
// b = a
b = refnew<object>(a);
// print id(a), id(b)
print(*refnew<List>(a, b))
// print a + b
print(a->add(*b));
// a = 5
refdel(a);
a = refnew<Int>(5);
So, we can see that, in python:
- attributions operate in the pointer
- method calls (that is, everything else, except id()) operate in the
object
And that's it. I think that there is confusion because everything we
do with python variables are pointer dereferences, except for the
attribution, that instead of dereferencing and operating the object,
just changes the pointer. The scope is just a matter of using
automatic memory management or not.
On Nov 27, 10:06 am, hdante <hda...@gmail.comwrote:
On Nov 25, 5:31 pm, none <""atavory\"@(none)"wrote:
.....
And that's it. I think that there is confusion because everything we
do with python variables are pointer dereferences, except for the
attribution, that instead of dereferencing and operating the object,
just changes the pointer. The scope is just a matter of using
automatic memory management or not.
I hope the participants in this thread realize
that this sort of discussion will cause
any programming newbie to immediately melt into the
floor.
I would try to avoid talking
in generalities about python variables versus C or
lisp or whatever, unless I was teaching an upper division
college programming languages survey class.
Instead, I'd fire up the interactive interpreter and
illustrate how things work via examples, avoiding the
weird cases at all costs. If they ask about the
relationship to C or java or whatever
I would encourage them to not worry about it,
and only go deeper if pressed.
BTW, at the moment I'm "facilitating" an online
C# class for fun and a very little profit in my
spare time. I'm becoming quite convinced that
especially the beginning programmers would have far
less difficulty with Python, largely because
there is less syntactic noise to confuse them and
because they can fiddle around with everything
up to and including advanced concepts using simple
examples at the interactive prompt.
But if you talk like the above to them, they
will run for the hills... (no offense intended).
-- Aaron Watters
=== http://www.xfeedme.com/nucular/pydis...TEXT=evil+fish
On Nov 27, 2007 10:25 AM, Aaron Watters <aa***********@gmail.comwrote:
On Nov 27, 10:06 am, hdante <hda...@gmail.comwrote:
On Nov 25, 5:31 pm, none <""atavory\"@(none)"wrote:
....
And that's it. I think that there is confusion because everything we
do with python variables are pointer dereferences, except for the
attribution, that instead of dereferencing and operating the object,
just changes the pointer. The scope is just a matter of using
automatic memory management or not.
I hope the participants in this thread realize
that this sort of discussion will cause
any programming newbie to immediately melt into the
floor.
Well, this (part of) the conversation was specifically about using the
knowledge that a C programmer already has and how best to teach them
how Python "variables" work in that context. I think that even the
people who disagree with my position would agree that, if your goal
were to teach a new student about Python variables, teaching them C
pointers first would be a really terrible way to go about it.
I would try to avoid talking
in generalities about python variables versus C or
lisp or whatever, unless I was teaching an upper division
college programming languages survey class.
I disagree, although it's not really on topic for the thread. There's
no reason why low level details need to be relegated to "upper
division" college classes. It shouldn't be in Programming Languages
101, but it's something that I would expect a first year student who's
planning to pursue a programming career or a comp sci degree to be
exposed to. It's not out of place even in high school - that's where I
first learned C.
Instead, I'd fire up the interactive interpreter and
illustrate how things work via examples, avoiding the
weird cases at all costs. If they ask about the
relationship to C or java or whatever
I would encourage them to not worry about it,
and only go deeper if pressed.
BTW, at the moment I'm "facilitating" an online
C# class for fun and a very little profit in my
spare time. I'm becoming quite convinced that
especially the beginning programmers would have far
less difficulty with Python, largely because
there is less syntactic noise to confuse them and
because they can fiddle around with everything
up to and including advanced concepts using simple
examples at the interactive prompt.
The idea of boxes with names is generally far more intuitive to
absolute beginners than pointers, if only because you have to
understand more of the underlying implementation to make use of
pointers. There's other (very good) reasons to use Python as a first
language for beginners, too.
But if you talk like the above to them, they
will run for the hills... (no offense intended).
-- Aaron Watters
In article
<f5**********************************@b40g2000prf. googlegroups.com>,
Aaron Watters <aa***********@gmail.comwrote:
I would try to avoid talking
in generalities about python variables versus C or
lisp or whatever, unless I was teaching an upper division
college programming languages survey class.
Instead, I'd fire up the interactive interpreter and
illustrate how things work via examples, avoiding the
weird cases at all costs. If they ask about the
relationship to C or java or whatever
I would encourage them to not worry about it,
and only go deeper if pressed.
I don't know if that explains enough on its own - I suppose
it depends on how ambitious your programmer is. But the
key point is that by approaching it this way, you're teaching
them how to teach themselves as required: write an example,
see what happens. A programmer who does this by reflex and
remains confused about how the language works is, in my opinion,
not going to get very far anyway. (This may have changed
somewhat in recent years as more esoteric junk has has been
stuffed into the language, I haven't really been keeping track.)
In contrast, I suspect that someone who learns Python concepts
in terms of explanations like `boxes' or `pointers' or whatnot
is at some disadvantage while that lasts, like translating a
foreign language to your own instead of attaching meaning
directly.
Donn Cave, do**@u.washington.edu
On Nov 26, 7:49 am, Hrvoje Niksic <hnik...@xemacs.orgwrote:
greg <g...@cosc.canterbury.ac.nzwrites:
none wrote:
IIRC, I once saw an explanation how Python doesn't have
"variables" in the sense that, say, C does, and instead has bindings
from names to objects.
If you're talking to C programmers, just tell them that Python
variables always contain pointers. That should give them the right
mental model to build on.
That is a convenient shortcut when it works, but in my experience it
tends to confuse the issue. The reason is that one of the main uses
of pointers in C is implementing pass-by-reference. A C programmer
told that Python variables internally hold pointers expects this code:
def func(a):
a = 10
...
func(x)
to change the value of x.
This shouldn't confuse a C programmer if he understands that
assignment changes the pointer address, instead of copying the value:
void func(int *a) {
int *tmp = malloc(sizeof(int));
*tmp = 10;
a = tmp;
free(tmp);
}
int *x = some_address;
func(x);
assert(x == some_address);
The confusion is that assignment does not copy the object. Python
variables are pointers and that's it.
On Nov 27, 11:52 am, "Chris Mellon" <arka...@gmail.comwrote:
I would try to avoid talking
in generalities about python variables versus C or
lisp or whatever, unless I was teaching an upper division
college programming languages survey class.
I disagree, although it's not really on topic for the thread. There's
no reason why low level details need to be relegated to "upper
division" college classes. It shouldn't be in Programming Languages
101, but it's something that I would expect a first year student who's
planning to pursue a programming career or a comp sci degree to be
exposed to. It's not out of place even in high school - that's where I
first learned C.
Well I learned PDP11 assembly and FORTRAN IV in high school
and I'm still recovering (taking it day by day).
Offline I would discuss anything the students wanted to
talk about, but during lecture or in reading, etcetera
I would try to stick to the "pythonic" way of looking
at things without worrying about the underlying
implementation, except in side references.
Yes, some boxes and arrows would be
very useful to explain shared side effects,
but I'd keep the diagrams limited.
I think thinking too much like "C" can lead to bad
practices -- for example I've seen people use the
global module name space more or less like any other
hash table -- adding, deleting, changing freely
-- and I think this was motivated by the
"C" level understanding that it really is just another
hash table. From a pythonic perspective you would
never think of behaving this way except under
extreme duress.
-- Aaron Watters
=== http://www.xfeedme.com/nucular/pydis...lting+delicate
Aurélien Campéas <sp***********************@free.frwrote (Sun, 25 Nov
2007 20:09:59 +0100):
none a écrit :
That's something I've often heard and I don't get it. Somehow I don't
understand how C variables are not like python bindings (the differences
being that C variables are statically typed and completely disappear at
run-time; are these differences important enough to warrant such a shift
in terminology ? (yes there are some other differences, but then the
question is asked in a context of pedagogy, where the audience is
introduced to the basics))
I mean : aren't C variables also bindings from names to objects ? Or what ?
This is actually something that comes up a lot on #python on freenode irc.
Usually we can explain it by calling things nametags that get bound to
objects and such, but sometimes it help to show people globals() and
locals() - that you can really just keep track of names with a dictionary
(And this is indeed, as I understand it, what's actually being done).
There's nothing that stops several names from being bound to the same
object, but names need to be unique. It's quite a good illustration, I
think. It certainly helped me. Oh, and there's the thing about people
calling them references, which isn't really accurate in the C++/Java or
pointer way.
Considering a C++/Java reference can actually change what it, in that if
you send a reference to a variable into a function/method, you can risk
that your own "copy" will be "pointing" (For a lack of better words) to a
different object. This won't happen in Python. Mutable objects make it
seem very similar though.
--
regards,
Robin
On Nov 27, 2:25 pm, Aaron Watters <aaron.watt...@gmail.comwrote:
>
I hope the participants in this thread realize
that this sort of discussion will cause
any programming newbie to immediately melt into the
floor.
All right, answering the original question is good. :-P
1) If the students can't program and you have chosen to teach them by
using python, then they don't have any "assignment == copy" hard-coded
in their minds. Just teach them that python assignments are like
creating aliases, or "mirrors". That is,
a = 2
Makes "a" an alias of 2.
l = [1, 2, 3]
Makes l[0] an alias of 1
Don't ever speak the word copy in class.
2) If the students come from different backgrounds, typically having
programmed in high level languages, like pascal, java, C#, etc, then
you may call python variables either aliases or references, but state
clearly that "assignment in python doesn't mean object copy, but
reference change".
3) If you're teaching in college, always show the students the formal
definition.
>
-- Aaron Watters
===http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=evil+fish
On Nov 27, 2:49 pm, Aaron Watters <aaron.watt...@gmail.comwrote:
In practice there is too much to understand all at
once and in the beginning you have to say "don't worry about that
right now, consider it magic..." Of course they should
eventually understand it.
Of course. But then it really depends on the teaching methodology,
doesn't it? There is no reason (well, barring the restraints of the
curriculum vitea), that one should learn topics so complex as to
require "off-putting" the *real* meaning until later, when one could
just as easily learn the basic concepts first. I guess it's a matter
of preference; whether you build from the top down (ala Berkley) or
the other way 'round.
Regards,
Jordan
On Tue, 27 Nov 2007 10:21:36 -0800, hdante wrote:
Python variables are pointers and that's it.
How do I increment a Python variable so that it points to the next
address, like I can do with pointers in C, Pascal, and other languages?
--
Steven.
none <""atavory\"@(none)"writes:
IIRC, I once saw an explanation how Python doesn't have
"variables" in the sense that, say, C does, and instead has bindings
from names to objects. Does anyone have a link?
"Variable" is an abstract concept, and it's a slightly different
concept for every programming language. So you're correct to say that
they're not like C variables. But putting it that way is no more valid
than saying that C doesn't have variables like Python's.
If you're teaching it from first principles then I wouldn't start by
saying what they're not, if people don't know what C variables are
then it doesn't help to say "these Python variables are not like C
variables". If they do know about variables in other languages, it
might help to say "forget your preconceptions about what a variable
is".
As you say, in Python variables are essentially names in some kind of
lookup table for objects... this is a perfectly reasonable way to try
and explain the idea (and is essentially the way it's
implemented). Then you have to get into scoping, and the odd gotcha
(e.g. contrast assigning to a global variable in local scope with
referencing one - with and without a "global" statement).
On Nov 28, 1:09 am, Steven D'Aprano
<ste...@REMOVE.THIS.cybersource.com.auwrote:
On Tue, 27 Nov 2007 10:21:36 -0800, hdante wrote:
Python variables are pointers and that's it.
How do I increment a Python variable so that it points to the next
address, like I can do with pointers in C, Pascal, and other languages?
--
Steven.
You can't. Python variables still are pointers. Hint:
int * const x = &y;
How do I increment x ?
On 2007-11-28, hdante <hd****@gmail.comwrote:
On Nov 28, 1:09 am, Steven D'Aprano
<ste...@REMOVE.THIS.cybersource.com.auwrote:
>On Tue, 27 Nov 2007 10:21:36 -0800, hdante wrote:
Python variables are pointers and that's it.
How do I increment a Python variable so that it points to the
next address, like I can do with pointers in C, Pascal, and
other languages?
--
Steven.
You can't. Python variables still are pointers. Hint:
int * const x = &y;
How do I increment x ?
Not only that, you can't point x at any other object at all.
That's not a Python variable either.
--
Neil Cerutti
On Nov 28, 1:42 pm, Neil Cerutti <horp...@yahoo.comwrote:
On 2007-11-28, hdante <hda...@gmail.comwrote:
On Nov 28, 1:09 am, Steven D'Aprano
<ste...@REMOVE.THIS.cybersource.com.auwrote:
On Tue, 27 Nov 2007 10:21:36 -0800, hdante wrote:
Python variables are pointers and that's it.
How do I increment a Python variable so that it points to the
next address, like I can do with pointers in C, Pascal, and
other languages?
--
Steven.
You can't. Python variables still are pointers. Hint:
int * const x = &y;
How do I increment x ?
Not only that, you can't point x at any other object at all.
That's not a Python variable either.
--
Neil Cerutti
That's right. Languages may have arbitrary sets of operations defined
for their variables. There's nothing wrong with that.
On 2007-11-28, hdante <hd****@gmail.comwrote:
On Nov 28, 1:42 pm, Neil Cerutti <horp...@yahoo.comwrote:
>On 2007-11-28, hdante <hda...@gmail.comwrote:
On Nov 28, 1:09 am, Steven D'Aprano
<ste...@REMOVE.THIS.cybersource.com.auwrote:
On Tue, 27 Nov 2007 10:21:36 -0800, hdante wrote:
Python variables are pointers and that's it.
>How do I increment a Python variable so that it points to the
next address, like I can do with pointers in C, Pascal, and
other languages?
>--
Steven.
You can't. Python variables still are pointers. Hint:
int * const x = &y;
How do I increment x ?
Not only that, you can't point x at any other object at all.
That's not a Python variable either.
That's right. Languages may have arbitrary sets of operations
defined for their variables. There's nothing wrong with that.
No, arbitrary operations would be useless.
--
Neil Cerutti
Scouts are saving aluminum cans, bottles, and other items to be recycled.
Proceeds will be used to cripple children. --Church Bulletin Blooper
On Nov 28, 2007 9:51 AM, hdante <hd****@gmail.comwrote:
On Nov 28, 1:42 pm, Neil Cerutti <horp...@yahoo.comwrote:
On 2007-11-28, hdante <hda...@gmail.comwrote:
On Nov 28, 1:09 am, Steven D'Aprano
><ste...@REMOVE.THIS.cybersource.com.auwrote:
>On Tue, 27 Nov 2007 10:21:36 -0800, hdante wrote:
Python variables are pointers and that's it.
>How do I increment a Python variable so that it points to the
>next address, like I can do with pointers in C, Pascal, and
>other languages?
>--
>Steven.
You can't. Python variables still are pointers. Hint:
int * const x = &y;
How do I increment x ?
Not only that, you can't point x at any other object at all.
That's not a Python variable either.
--
Neil Cerutti
That's right. Languages may have arbitrary sets of operations defined
for their variables. There's nothing wrong with that.
Right. Python variables are pointers, except for all the ways that
they are different. By the same criteria, they are also puppies. Give
it a rest.
On Nov 28, 2:06 pm, Neil Cerutti <horp...@yahoo.comwrote:
>
That's right. Languages may have arbitrary sets of operations
defined for their variables. There's nothing wrong with that.
No, arbitrary operations would be useless.
1) You may convince a big company to add you newly developed
arbitrary operation to their compiler.
2) You may give support to developers who have problems with the
arbitrary operation.
3) You'll be able to better quantify the failure rate of your
applications.
4) You'll be able to create an emotional bond between the users and
your software.
--
Neil Cerutti
Scouts are saving aluminum cans, bottles, and other items to be recycled.
Proceeds will be used to cripple children. --Church Bulletin Blooper
On Nov 28, 2:12 pm, "Chris Mellon" <arka...@gmail.comwrote:
>
Right. Python variables are pointers, except for all the ways that
they are different. By the same criteria, they are also puppies. Give
it a rest.
I'm sorry if your notion of pointer is incorrect. A pointer (or, more
formally, a reference) is an object that points to some value. A
python variable isn't different than that in any way.
On Nov 28, 2007 10:57 AM, hdante <hd****@gmail.comwrote:
On Nov 28, 2:12 pm, "Chris Mellon" <arka...@gmail.comwrote:
Right. Python variables are pointers, except for all the ways that
they are different. By the same criteria, they are also puppies. Give
it a rest.
I'm sorry if your notion of pointer is incorrect. A pointer (or, more
formally, a reference) is an object that points to some value. A
python variable isn't different than that in any way.
A python name isn't an object. The difference between names and
objects is at the core of this entire conversation. In fact, you are
exactly the sort of person this discussion was targeted at, because
you don't understand the difference.
You can play semantic games if you want and just declare that
everything is the same at some fundamental level. It's a little like
taking your ball and going home, because insisting on names that don't
indicate the differences between things is useless at best and harmful
at worst.
Whether you like it or not, the term "pointer" has a specific common
meanings. They do not mean "any means by which you may reference a
value". "variable" is certainly less clear and is used much more
loosely, but in the specific context of comparison to C, python
name/object bindings are not the same as C variables.
Pointers are values. They also point at other values, and those values
may be other pointers, ad infinitum. Understanding this is core to
understanding and using pointers.
Python names are *not* values, and all they do is tag a specific
object in a specific namespace. You can't have a name that refers to
another name, names can only refer to objects. Understanding this is
core to understanding and using the Python object model, *especially*
if some nitwit has been telling you that they're the same as pointers.
On Wed, Nov 28, 2007 at 11:23:42AM -0600, Chris Mellon wrote regarding Re: How to Teach Python "Variables":
>
On Nov 28, 2007 10:57 AM, hdante <hd****@gmail.comwrote:
On Nov 28, 2:12 pm, "Chris Mellon" <arka...@gmail.comwrote:
>
Right. Python variables are pointers, except for all the ways that
they are different. By the same criteria, they are also puppies. Give
it a rest.
I'm sorry if your notion of pointer is incorrect. A pointer (or, more
formally, a reference) is an object that points to some value. A
python variable isn't different than that in any way.
A python name isn't an object. The difference between names and
objects is at the core of this entire conversation. In fact, you are
exactly the sort of person this discussion was targeted at, because
you don't understand the difference.
You can play semantic games if you want and just declare that
everything is the same at some fundamental level. It's a little like
taking your ball and going home, because insisting on names that don't
indicate the differences between things is useless at best and harmful
at worst.
Whether you like it or not, the term "pointer" has a specific common
meanings. They do not mean "any means by which you may reference a
value". "variable" is certainly less clear and is used much more
loosely, but in the specific context of comparison to C, python
name/object bindings are not the same as C variables.
Pointers are values. They also point at other values, and those values
may be other pointers, ad infinitum. Understanding this is core to
understanding and using pointers.
Python names are *not* values, and all they do is tag a specific
object in a specific namespace. You can't have a name that refers to
another name, names can only refer to objects. Understanding this is
core to understanding and using the Python object model, *especially*
if some nitwit has been telling you that they're the same as pointers.
--
http://mail.python.org/mailman/listinfo/python-list
OK, now we're down to mock sympathy, insulting analogies and name-calling. Can we just let this thread die. It was an interesting discussion for a while, but it's moved into that ugly putrefaction stage now. Nothing new is being said, and the old stuff is being said more rudely than before.
This thread is bleedin' demised.
Cheers,
Cliff
"Chris Mellon" <ar*****@gmail.comwrites:
Whether you like it or not, the term "pointer" has a specific common
meanings. They do not mean "any means by which you may reference a
value". "variable" is certainly less clear and is used much more
loosely, but in the specific context of comparison to C, python
name/object bindings are not the same as C variables.
Yes.
Further, "in the specific context of comparison to C" was all this
thread was *ever* about at the beginning:
none <""atavory\"@(none)"writes:
Hello,
IIRC, I once saw an explanation how Python doesn't have
"variables" in the sense that, say, C does, and instead has bindings
from names to objects. Does anyone have a link?
So please, let's stop trying to brinng up "pointer" and "variable"
with some pure language-independent meaning that is the only one we
should consider. The *specific context* here is the existing
preconceptions programmers bring from other languages like C.
--
\ "Anytime I see something screech across a room and latch onto |
`\ someone's neck, and the guy screams and tries to get it off, I |
_o__) have to laugh, because what is that thing?" -- Jack Handey |
Ben Finney
"J. Clifford Dyer" <jc...nestar.orgwrote:
This thread is bleedin' demised.
No, you have stunned it.
Delicate threads stun easily.
To get back to the original question, namely how to teach
the concept of a python variable, I would probably take
a harder look at the "wandering names" analogy. I think it
was first mentioned some time ago in a similar context
by Dennis.
Heinz = 42
Heinz = [1,2,3,4]
Where is Heinz now?
He is masquerading as a list, after having been an integer...
But he suffers from amnesia, he can't remember his integer days.
And what about the 42?
It is still lurking in limbo, waiting to be Garbage Collected or
resurrected by a new assignment.
- Hendrik This thread has been closed and replies have been disabled. Please start a new discussion. |
