How to Teach Python "Variables"
none
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
Aurélien Campéas
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 ?
Diez B. Roggisch
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
none
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.
Aahz
http://starship.python.net/crew/mwh/hacks/objectthink.html
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"Typing is cheap. Thinking is expensive." --Roy Smith
Andrew Koenig
news:4749c888$0$14869$426a...@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.
none
> In article <4749bb94$1...@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/hacks/objectthink.html
Thanks!
Bjoern Schliessmann
> 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.
Ben Finney
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
none
> 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.
>
greg
> 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
Simon Brunning
Perhaps you mean:
http://effbot.org/zone/python-objects.htm
--
Cheers,
Simon B.
si...@brunningonline.net
http://www.brunningonline.net/simon/blog/
GTalk: simon.brunning | MSN: small_values | Yahoo: smallvalues
Hrvoje Niksic
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.
davis...@gmail.com
> greg <gr...@cosc.canterbury.ac.nz> writes:
>
> > 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
Chris Mellon
> Hrvoje Niksic wrote:
> > greg <gr...@cosc.canterbury.ac.nz> writes:
> >
> > > 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.
jkn
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.lang.python/browse_frm/thread/
56e7d62bf66a435c/ab62283cde9e4c63#ab62283cde9e4c63>
J^n
Steven D'Aprano
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
davis...@gmail.com
> On Nov 26, 2007 1:21 PM, davis...@gmail.com <davis...@gmail.com> wrote:
> > Hrvoje Niksic wrote:
> > > greg <gr...@cosc.canterbury.ac.nz> writes:
> > >
> > > > 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
greg
> 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
Neil Cerutti
> Hrvoje Niksic wrote:
>> greg <gr...@cosc.canterbury.ac.nz> writes:
>>
>> > 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
hdante
(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.
Aaron Watters
> 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/pydistro.py/go?FREETEXT=evil+fish
Chris Mellon
> On Nov 27, 10:06 am, hdante <hda...@gmail.com> wrote:
> > 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.
Donn Cave
<f5259aca-b49a-4ef2...@b40g2000prf.googlegroups.com>,
Aaron Watters <aaron....@gmail.com> wrote:
> 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
hdante
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.
Aaron Watters
> > 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/pydistro.py/go?FREETEXT=revolting+delicate
Robin Kåveland
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
hdante
>
> 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
MonkeeSage
> 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.
I agree with your point, but I think the distinction is this:
pedagogical analogies should be truly *analogous* -- they should not
be "analogies" that are only vaguely similar and require you to
constantly say "...but ignore this difference and that
difference...oh, and that one...you'll learn that later." I personally
think the "ignore this for now" approach is detrimental. An example of
a real analogy, which is very useful (imho), is in regards to C
pointers. The analogy is to a real pointing device (nowadays, probably
a laser pointer). The pointer (pointing device) is one thing, and it
takes up its own dimensions of space; but it can point to something
else, and that something takes up its own dimensions as well. They are
not interchangeable; they have their own identities. But by following
the pointer to the something else, and interpreting that something
according to its own nature (text, a picture, &c), you can find the
"value" of the pointer. The pointer merely "references" that value.
And you can exchange the value that is referred to with any other
value of the same nature. You can, for example, point to a line of
code on an overhead projector. Then you can change the slide. Now the
value of the reference has changed, but the reference is the same. And
you can go one step further and point at an arrow symbol, which in
turn points to some other value in the context; the value turns out to
be another pointer which can be followed to it's own meaning. Granted,
it's an analogy, but I think it's a *good* analogy rather than a bad
one; it helps map the meaning to familiar objects, rather than the
trappings of the familiar preventing from grasping the concept.
Regards,
Jordan
Aaron Watters
> On Nov 27, 11:50 am, Donn Cave <d...@u.washington.edu> wrote:
> I agree with your point, but I think the distinction is this:
> pedagogical analogies should be truly *analogous* -- they should not
> be "analogies" that are only vaguely similar and require you to
> constantly say "...but ignore this difference and that
> difference...oh, and that one...you'll learn that later." I personally
Yes, in theory. And in theory, theory is the same as practice.
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.
Again, this is another place where Python shines, because
the front end scary magic is limited -- you can start out
with simple and useful imperative
straight line scripts and then move
into higher levels from there -- in contrast to C# and java
which require you to declare a class with static methods
even if you have no intention of writing any OO code.
Beginners find this incredibly confusing and scary.
Magic should never be permanent, however.
In the case of Struts or Spring there is magic
that no one is ever intended to truly understand.
Danger Will Robinson! Danger!
This is my problem also with
most web application frameworks, even in Python
-- too much strange magic floats around in the air
-- usually in order to make things "easy" that I never thought
were hard in the first place.
-- Aaron Watters
===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=lame+hack+wink
MonkeeSage
> 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
Steven D'Aprano
> 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.
Paul Rudin
> 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).
Aaron Watters
> 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.
As you hint, this is the tip of the iceberg
of some very complex philosophical issues.
For practical instruction I think there is
overwhelming evidence you can't "begin at the beginning".
In mathematics you really can't teach starting
with the axioms of set theory and build up from
there -- you'd never get to long division before
the students will have given up long ago.
Similarly, in computer science you can't just
go off to the beach to get some sand to start
building a computer. (Although when I was
at Bell Labs the joke was that that was the
Bell Labs attitude.)
In practice you always have to start in the
middle and tell the students not to worry
about stuff that would add an overwhelming
amount of detail. For example, most beginning
students will have a vague idea what
the filesystem is, even though they will
have to deal with it a lot -- and you don't
want to get mired down for the first few weeks
trying to talk about the filesystem. Instead
you say "follow these steps and all will
become clear later." It's not a matter of
preference -- it's a matter of necessity.
-- Aaron Watters
===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=lazy+future+generation
hdante
You can't. Python variables still are pointers. Hint:
int * const x = &y;
How do I increment x ?
Neil Cerutti
Not only that, you can't point x at any other object at all.
That's not a Python variable either.
--
Neil Cerutti
hdante
That's right. Languages may have arbitrary sets of operations defined
for their variables. There's nothing wrong with that.
Neil Cerutti
> On Nov 28, 1:42 pm, Neil Cerutti <horp...@yahoo.com> wrote:
>> On 2007-11-28, hdante <hda...@gmail.com> wrote:
>>
>>
>>
>> > On Nov 28, 1:09 am, Steven D'Aprano
>> ><ste...@REMOVE.THIS.cybersource.com.au> wrote:
>> >> 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.
>
> 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
Chris Mellon
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.
hdante
>
> > 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.
hdante
>
> 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.
Chris Mellon
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.
J. Clifford Dyer
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 <hda...@gmail.com> wrote:
> 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
Ben Finney
"Chris Mellon" <ark...@gmail.com> writes:
> 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
MonkeeSage
I agree. I think that perhaps I overstated my point. Given that a
subject remains within the realm of intuition, I see no reason to hide
information; but after a certain (admittedly subjective) boundery,
things stop making intuitive sense (e.g., "what do you mean that my
computer is made of sand?" or "what do you mean that what goes on in
my computer is no different than plugging in a toaster?"). I just
don't see the merit in some approaches, where one starts a CS course
with C#/C++/Java and 75% of the language you have to "ignore for now."
I think that type of approach leads to bad practices to say the least.
But indeed, there is a happy medium! You don't want to start with
assembler...but at the same time (my contention) you don't want to
start with "private static void" either. You want to start in the
happy medium, where analogies (*good* analogies) can be of no end of
helpfulness.
Regards,
Jordan
Hendrik van Rooyen
"J. Clifford Dyer" <jc...nestar.org> wrote:
> 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