In the section on functions, Magnus Lie Hetland writes:
-------------------------------------------------------------------- For those of you who understand it: When you pass a parameter to a function, you bind the parameter to the value, thus creating a new reference. If you change the “contents” of this parameter name (i.e. rebind it) that won’t affect the original. This works just like in Java, for instance. Let’s take a look at an example:
def change(some_list): some_list[1] = 4
x = [1,2,3] change(x) print x # Prints out [1,4,3]
As you can see, it is the original list that is passed in, and if the function changes it, these changes carry over to the place where the function was called. Note, however the behaviour in the following example:
def nochange(x): x = 0
y = 1 nochange(y) print y # Prints out 1
Why is there no change now? Because we don’t change the value! The value that is passed in is the number 1 — we can’t change a number in the same way that we change a list. The number 1 is (and will always be) the number 1. What we did do is change the contents of the local variable (parameter) x, and this does not carry over to the environment. --------------------------------------------------------------------
What this looks like to me is what would happen if in C I passed a pointer to the list x to the function change(), as in:
change(&x);
Thus the function could change the original list.
I don't understand Hetland's terminology though, when he is speaking of "binding" and "reference." Actually, Hetland's entire first paragraph is unclear.
Can anyone reword this in a way that is understandable?
Thanks.
-- Good day!
________________________________________ Christopher R. Carlen Principal Laser&Electronics Technologist Sandia National Laboratories CA USA crcarleRemoveT...@BOGUSsandia.gov NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.
> In the section on functions, Magnus Lie Hetland writes:
> -------------------------------------------------------------------- > For those of you who understand it: When you pass a parameter to a > function, you bind the parameter to the value, thus creating a new > reference. If you change the “contents” of this parameter name (i.e. > rebind it) that won’t affect the original. This works just like in Java, > for instance. Let’s take a look at an example:
> def change(some_list): > some_list[1] = 4
> x = [1,2,3] > change(x) > print x # Prints out [1,4,3]
> As you can see, it is the original list that is passed in, and if the > function changes it, these changes carry over to the place where the > function was called. Note, however the behaviour in the following > example:
> def nochange(x): > x = 0
> y = 1 > nochange(y) > print y # Prints out 1
> Why is there no change now? Because we don’t change the value! The value > that is passed in is the number 1 — we can’t change a number in the same > way that we change a list. The number 1 is (and will always be) the > number 1. What we did do is change the contents of the local variable > (parameter) x, and this does not carry over to the environment. > --------------------------------------------------------------------
> What this looks like to me is what would happen if in C I passed a > pointer to the list x to the function change(), as in:
> change(&x);
> Thus the function could change the original list.
> I don't understand Hetland's terminology though, when he is speaking of > "binding" and "reference." Actually, Hetland's entire first paragraph > is unclear.
> Can anyone reword this in a way that is understandable?
Now, forget about C "variables" and "pointers" because you won't get much far with those concepts. Objects exist - and we usually use names to refer to them. This line:
a = 1
means "make the name 'a' refer to the object 1", or, "bind the name 'a' to the instance of type int with value 1", or "let 'a' be a reference to the object 1"
This line:
some_list[1] = 4
means "make the second element of some_list refer to the object 4", or "alter some_list so its element [1] is a reference to the object 4"
bind the name 'a' to the instance of type int with value 1", or "let 'a' be a reference to the object 1"
Note that some objects are immutable - like the number 1, which will always be the number 1 (*not* an integer "variable" that can hold any integer value). Other objects -like lists and dictionaries, by example, or most user defined classes- are mutable, and you can change its contents and properties. Modifying an object is not the same as rebinding its name:
x = [1,2,3] y = x x[1] = 4 print x # [1, 4, 3] print y # [1, 4, 3]
x = [1,2,3] y = x x = [1,4,3] print x # [1, 4, 3] print y # [1, 2, 3]
You can test is two names refer to the same object using the is operator: x is y. You will get True in the first case and False in the second case.
Chris Carlen <crcarleRemoveT...@BOGUSsandia.gov> writes: > I don't understand Hetland's terminology though, when he is speaking > of "binding" and "reference." Actually, Hetland's entire first > paragraph is unclear.
> Can anyone reword this in a way that is understandable?
I've had some success with the following way of thinking about it.
Some languages have "variables", which act like boxes that have names etched on the side. Once created, the box can contain an object, and it can be inspected while in the box; to change the variable, you throw out the object and put a different object in the same box.
That's not how Python works. Every value is an object; the assignment operator binds a name to an object. This is more like writing the name on a sticky-note, and sticking it onto the object.
* The object itself doesn't change or "move".
* The object can be referred to by that name, but isn't "inside" the name in any way.
* Assigning multiple names to the same object just means you can refer to that same object by all those names.
* When a name goes away, the object still exists -- but it can't be referred to if there are no longer any names left on it.
* Assigning a different object to an existing name just means that the same sticky-note has moved from the original object to the new one. Referring to the same name now references a different object, while the existing object keeps all the other names it had.
When you pass an object as a parameter to a function, the object receives a new sticky-label: the parameter name under which it was received into the function scope. Assignment is an act of binding a name to an object; no new object is created, and it still has all the other names it had before.
When the function ends, all the names that were created inside that function's scope disappear; but the objects still exist under any names they had previously, and if you use those names you'll be looking at the same object as was manipulated inside the function.
When the object has lost all its names -- for example, they've disappeared because the scope they were in has closed, or they've been re-bound to other objects -- they can no longer be referenced. At some point after that, the automatic garbage collection will clean that object out of memory.
This sticky-note analogy, and the behaviour described, is what is meant by "references". A name refers to an object; changing the object means that by referring to that same object under its different names, you will see the same, modified, object.
In Python, all names are references to objects. The assignment operator '=' doesn't create or change a "variable"; instead, it binds a name as reference to an object. All functions receive their parameters as the existing object with a new name -- a reference to that object, just like any other name.
Hope that helps.
-- \ "If you ever teach a yodeling class, probably the hardest thing | `\ is to keep the students from just trying to yodel right off. | _o__) You see, we build to that." -- Jack Handey | Ben Finney
Gabriel Genellina wrote: > En Thu, 12 Jul 2007 21:51:08 -0300, Chris Carlen > <crcarleRemoveT...@BOGUSsandia.gov> escribió: >> http://hetland.org/writing/instant-python.html >> I don't understand Hetland's terminology though, when he is speaking of >> "binding" and "reference." Actually, Hetland's entire first paragraph >> is unclear. > First, see this short article http://effbot.org/zone/python-objects.htm
I'll have a look.
> Now, forget about C "variables" and "pointers" because you won't get > much far with those concepts.
> Objects exist - and we usually use names to refer to them. This line:
> a = 1
> means "make the name 'a' refer to the object 1", or, "bind the name 'a' > to the instance of type int with value 1", or "let 'a' be a reference > to the object 1"
> This line:
> some_list[1] = 4
> means "make the second element of some_list refer to the object 4", or > "alter some_list so its element [1] is a reference to the object 4"
> bind the name 'a' to the instance of type int with value 1", or "let > 'a' be a reference to the object 1"
> Note that some objects are immutable - like the number 1, which will > always be the number 1 (*not* an integer "variable" that can hold any > integer value). Other objects -like lists and dictionaries, by example, > or most user defined classes- are mutable, and you can change its > contents and properties. Modifying an object is not the same as > rebinding its name:
> x = [1,2,3] > y = x > x[1] = 4 > print x # [1, 4, 3] > print y # [1, 4, 3]
Thanks to your explanation, I understand!
> x = [1,2,3] > y = x > x = [1,4,3] > print x # [1, 4, 3] > print y # [1, 2, 3]
> You can test is two names refer to the same object using the is > operator: x is y. You will get True in the first case and False in the > second case.
I don't quite get this "x is y" stuff yet.
Let's go back the statement:
x = [1,2,3]
Do we then say: "[1,2,3] is x" or is it the other way around: "x is [1,2,3]" ???
I think it is the former in Python, whereas it would be the latter in C.
So Python is like saying "I am Chris Carlen."
This is actually completely ridiculous, since I am me, not my name. The name refers to me. I get that. Yet our spoken language puts it in a way which is backwards.
Thanks for the input.
-- Good day!
________________________________________ Christopher R. Carlen Principal Laser&Electronics Technologist Sandia National Laboratories CA USA crcarleRemoveT...@BOGUSsandia.gov NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.
Chris Carlen wrote: > Let's go back the statement:
> x = [1,2,3]
> Do we then say: "[1,2,3] is x" or is it the other way around: "x is > [1,2,3]" ???
This will yield 'False', because 'is' checks for *identity* not equality. In your case you assign a list the name 'x' and then check (via the 'is' operator) if it is the same object as another (newly created) list. While they are equal (same class and contents) they are not the same. Try this:
x = [1, 2, 3] y = [1, 2, 3] id(x), id(y) x == y x is y
Then you'll see.
> This is actually completely ridiculous, since I am me, not my name. The > name refers to me. I get that. Yet our spoken language puts it in a > way which is backwards.
To stress the point: "a is b" has the same meaning as "b is a". It does not check for "being a certain thing" (as in "Archimedes is a human") but rather for "one thing beeing the exact same as the other" (as in "Superman is Clark Kent").
Ben Finney wrote: > Chris Carlen <crcarleRemoveT...@BOGUSsandia.gov> writes:
> def change(some_list): > some_list[1] = 4
> x = [1,2,3] > change(x) > print x # Prints out [1,4,3]
> --- > def nochange(x): > x = 0 > > y = 1 > nochange(y) > print y # Prints out 1 >
>>I don't understand Hetland's terminology though, when he is speaking >>of "binding" and "reference." Actually, Hetland's entire first >>paragraph is unclear.
>>Can anyone reword this in a way that is understandable?
> I've had some success with the following way of thinking about it.
> Some languages have "variables", which act like boxes that have names > etched on the side. Once created, the box can contain an object, and > it can be inspected while in the box; to change the variable, you > throw out the object and put a different object in the same box.
Yes, so y = x takes a copy of the stuff in the x box and puts it in the y box. Which is what really happens in the hardware.
> That's not how Python works. Every value is an object; the assignment > operator binds a name to an object. This is more like writing the name > on a sticky-note, and sticking it onto the object.
> * The object itself doesn't change or "move".
> * The object can be referred to by that name, but isn't "inside" the > name in any way.
> * Assigning multiple names to the same object just means you can > refer to that same object by all those names.
> * When a name goes away, the object still exists -- but it can't be > referred to if there are no longer any names left on it.
> * Assigning a different object to an existing name just means that > the same sticky-note has moved from the original object to the new > one. Referring to the same name now references a different object, > while the existing object keeps all the other names it had.
Excellent description. This understandable to me since I can envision doing this with pointers. But I have no idea how Python actually implements this. It also appears that I am being guided away from thinking about it in terms of internal implementation.
> When you pass an object as a parameter to a function, the object > receives a new sticky-label: the parameter name under which it was > received into the function scope. Assignment is an act of binding a > name to an object; no new object is created, and it still has all the > other names it had before.
Ok, so I can understand the code above now.
In the first case I pass the reference to the list to change(). In the function, some_list is another name referring to the actual object [1,2,3]. Then the function changes the object referred to by the second element of the list to be a 4 instead of a 2. (Oh, the concept applies here too!) Out of the function, the name x refers to the list which has been changed.
In the second case, y refers to a '1' object and when the function is called the object 1 now gets a new reference (name) x inside the function. But then a new object '0' is assigned to the x name. But the y name still refers to a '1'.
I get it. But I don't like it. Yet. Not sure how this will grow on me.
> When the function ends, all the names that were created inside that > function's scope disappear; but the objects still exist under any > names they had previously, and if you use those names you'll be > looking at the same object as was manipulated inside the function.
> When the object has lost all its names -- for example, they've > disappeared because the scope they were in has closed, or they've been > re-bound to other objects -- they can no longer be referenced. At some > point after that, the automatic garbage collection will clean that > object out of memory.
> This sticky-note analogy, and the behaviour described, is what is > meant by "references". A name refers to an object; changing the object > means that by referring to that same object under its different names, > you will see the same, modified, object.
> In Python, all names are references to objects. The assignment > operator '=' doesn't create or change a "variable"; instead, it binds > a name as reference to an object. All functions receive their > parameters as the existing object with a new name -- a reference to > that object, just like any other name.
> Hope that helps.
A great deal of help, thanks. Excellent explanation. Wow. This is strange. A part of me wants to run and hide under the nearest 8-bit microcontroller. But I will continue learning Python.
-- Good day!
________________________________________ Christopher R. Carlen Principal Laser&Electronics Technologist Sandia National Laboratories CA USA crcarleRemoveT...@BOGUSsandia.gov NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.
> Ben Finney wrote: > > Chris Carlen <crcarleRemoveT...@BOGUSsandia.gov> writes: > > That's not how Python works. Every value is an object; the assignment > > operator binds a name to an object. This is more like writing the name > > on a sticky-note, and sticking it onto the object.
> > * The object itself doesn't change or "move".
> > * The object can be referred to by that name, but isn't "inside" the > > name in any way.
> > * Assigning multiple names to the same object just means you can > > refer to that same object by all those names.
> > * When a name goes away, the object still exists -- but it can't be > > referred to if there are no longer any names left on it.
> > * Assigning a different object to an existing name just means that > > the same sticky-note has moved from the original object to the new > > one. Referring to the same name now references a different object, > > while the existing object keeps all the other names it had.
> Excellent description. This understandable to me since I can envision > doing this with pointers. But I have no idea how Python actually > implements this. It also appears that I am being guided away from > thinking about it in terms of internal implementation.
I assume that you're familiar with the general concept of hash tables. Scopes in Python are hash tables mapping strings to Python objects. Names are keys into the hash table.
a = 10
is the same as currentScope["a"] = 10
print a
is the same as print currentScope["a"]
As you can see, there's no way that assignment can result in any sort of sharing. The only way that changes can be seen between shared objects is if they are mutated via mutating methods.
Python objects (the values in the hashtable) are refcounted and can be shared between any scope.
> > When you pass an object as a parameter to a function, the object > > receives a new sticky-label: the parameter name under which it was > > received into the function scope. Assignment is an act of binding a > > name to an object; no new object is created, and it still has all the > > other names it had before.
Each scope is it's own hashtable. The values can be shared, but not the keys. When you call a function, the objects (retrieved from the callers local scope by name) are inserted into the functions local scope, bound to the names in the function signature. This is what Guido calls "call by object reference".
> In the first case I pass the reference to the list to change(). In the > function, some_list is another name referring to the actual object > [1,2,3]. Then the function changes the object referred to by the second > element of the list to be a 4 instead of a 2. (Oh, the concept applies > here too!) Out of the function, the name x refers to the list which has > been changed.
> In the second case, y refers to a '1' object and when the function is > called the object 1 now gets a new reference (name) x inside the > function. But then a new object '0' is assigned to the x name. But the > y name still refers to a '1'.
> I get it. But I don't like it. Yet. Not sure how this will grow on me.
You need to learn about Pythons scoping now, not it's object passing semantics. When you're used to thinking in terms of pointers and memory addresses it can take some work to divorce yourself from those habits.
<wilde...@freakmail.de> wrote: >Wildemar Wildenburger wrote: >> x = [1, 2, 3] >> y = [1, 2, 3] >> id(x), id(y) >> x == y >> x is y
>Ooops!
>Make that:
>x = [1, 2, 3] >y = [1, 2, 3] >id(x); id(y) >x == y >x is y
>(had to be a semicolon there)
Not "had to be" since a discerning reader will note that the two values in the list:
>>> id(x), id(y) (19105872, 19091664)
are different, and can guess that id() means "address of". But "nicer to be" perhaps since it makes it even more clea rto discerning readers, and more likely clear to others. ;-)
Chris Mellon wrote: > On 7/13/07, Chris Carlen <crcarleRemoveT...@bogussandia.gov> wrote: >> Ben Finney wrote: >>> Chris Carlen <crcarleRemoveT...@BOGUSsandia.gov> writes:
>>> That's not how Python works. Every value is an object; the assignment >>> operator binds a name to an object. This is more like writing the name >>> on a sticky-note, and sticking it onto the object.
>>> * The object itself doesn't change or "move".
>>> * The object can be referred to by that name, but isn't "inside" the >>> name in any way.
>>> * Assigning multiple names to the same object just means you can >>> refer to that same object by all those names.
>>> * When a name goes away, the object still exists -- but it can't be >>> referred to if there are no longer any names left on it.
>>> * Assigning a different object to an existing name just means that >>> the same sticky-note has moved from the original object to the new >>> one. Referring to the same name now references a different object, >>> while the existing object keeps all the other names it had. >> Excellent description. This understandable to me since I can envision >> doing this with pointers. But I have no idea how Python actually >> implements this. It also appears that I am being guided away from >> thinking about it in terms of internal implementation.
> I assume that you're familiar with the general concept of hash tables. > Scopes in Python are hash tables mapping strings to Python objects. > Names are keys into the hash table.
> a = 10
> is the same as > currentScope["a"] = 10
> print a
> is the same as > print currentScope["a"]
> As you can see, there's no way that assignment can result in any sort > of sharing. The only way that changes can be seen between shared > objects is if they are mutated via mutating methods.
> Python objects (the values in the hashtable) are refcounted and can be > shared between any scope.
>>> When you pass an object as a parameter to a function, the object >>> receives a new sticky-label: the parameter name under which it was >>> received into the function scope. Assignment is an act of binding a >>> name to an object; no new object is created, and it still has all the >>> other names it had before.
> Each scope is it's own hashtable. The values can be shared, but not > the keys. When you call a function, the objects (retrieved from the > callers local scope by name) are inserted into the functions local > scope, bound to the names in the function signature. This is what > Guido calls "call by object reference".
This is, of course, something of an oversimplification. First, the global statement allows you to modify a name of module scope from inside another scope such as a functions.
>> In the first case I pass the reference to the list to change(). In the >> function, some_list is another name referring to the actual object >> [1,2,3]. Then the function changes the object referred to by the second >> element of the list to be a 4 instead of a 2. (Oh, the concept applies >> here too!) Out of the function, the name x refers to the list which has >> been changed.
>> In the second case, y refers to a '1' object and when the function is >> called the object 1 now gets a new reference (name) x inside the >> function. But then a new object '0' is assigned to the x name. But the >> y name still refers to a '1'.
>> I get it. But I don't like it. Yet. Not sure how this will grow on me.
> You need to learn about Pythons scoping now, not it's object passing > semantics. When you're used to thinking in terms of pointers and > memory addresses it can take some work to divorce yourself from those > habits.
Then, of course, there are the nested scoping rule for functions defined inside other functions.
regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --------------- Asciimercial ------------------ Get on the web: Blog, lens and tag the Internet Many services currently offer free registration ----------- Thank You for Reading -------------
> Excellent description. This understandable to me since I can envision > doing this with pointers. But I have no idea how Python actually > implements this.
The code source is freely available, and it's in C !-)
> It also appears that I am being guided away from > thinking about it in terms of internal implementation.
Indeed. Python *is* a hi-level language, and it's main benefit (wrt to lower-level languages like C or Pascal) is to let you think more in terms of "what" than in terms of "how".
En Fri, 13 Jul 2007 13:41:39 -0300, Chris Carlen <crcarleRemoveT...@BOGUSsandia.gov> escribió:
> Ben Finney wrote: >> Some languages have "variables", which act like boxes that have names >> etched on the side. Once created, the box can contain an object, and >> it can be inspected while in the box; to change the variable, you >> throw out the object and put a different object in the same box.
> Yes, so y = x takes a copy of the stuff in the x box and puts it in the > y box. Which is what really happens in the hardware.
At least on some hardware, yes. Python namespaces are more like associative memories: you bind a tag (name) to a value, they have constant access time... But the real gain comes when you don't have to explicitely think step by step on *how* to do things, and can concentrate on a more abstract layer and say *what* you want to be done.
> I get it. But I don't like it. Yet. Not sure how this will grow on me.
> A great deal of help, thanks. Excellent explanation. Wow. This is > strange. A part of me wants to run and hide under the nearest 8-bit > microcontroller. But I will continue learning Python.
I think you will like it in the near future. But for someone coming from the microcontroller world, used to think closely in terms of the implementation, this may be a big paradigm shift.
Chris Carlen <crcarleRemoveT...@BOGUSsandia.gov> writes: > Excellent description. This understandable to me since I can > envision doing this with pointers.
It would be better if you thought in terms of "refrences". Python names are unlike pointers in that they don't "store" anything. The *only* thing to do with them is refer to an object; don't think of them as a C pointer, because Python names don't need to be (and, indeed, can't) be "de-referenced".
> But I have no idea how Python actually implements this. It also > appears that I am being guided away from thinking about it in terms > of internal implementation.
Yes. This is a good thing, because Python has multiple implementations that are allowed to differ in their internals where it makes sense to do so. There are some guarantees at a lower level, that you can find in the language reference; but the main advantage of stopping at a certain level of abstraction is that the implementation programmers are free to *change* the implementation underneath that abstraction when it will improve the implementation.
Meanwhile, the Python programmer is free to work at the abstraction level provided by the language, and isn't forced to be always mindful of the inner workings if the current implementation.
-- \ "To me, boxing is like a ballet, except there's no music, no | `\ choreography, and the dancers hit each other." -- Jack Handey | _o__) | Ben Finney
|
