Understanding python functions - Instant Python tutorial
Chris Carlen
I have begun learning Python by experimenting with the code snippets here:
http://hetland.org/writing/instant-python.html
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
crcarleR...@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.
Gabriel Genellina
<crcarleR...@BOGUSsandia.gov> escribió:
First, see this short article http://effbot.org/zone/python-objects.htm
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.
--
Gabriel Genellina
Ben Finney
> 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
Chris Carlen
> En Thu, 12 Jul 2007 21:51:08 -0300, Chris Carlen
> <crcarleR...@BOGUSsandia.gov> escribió:
>> I don't understand Hetland's terminology though, when he is speaking of
>> "binding" and "reference." Actually, Hetland's entire first paragraph
>> is unclear.
I'll have a look.
> Now, forget about C "variables" and "pointers" because you won't get
> much far with those concepts.
Ok, painful, but I'll try.
> 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.
Wildemar Wildenburger
> 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]" ???
>
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").
Chris Carlen
> Chris Carlen <crcarleR...@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
>
>>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.
Wildemar Wildenburger
> x = [1, 2, 3]
> y = [1, 2, 3]
> id(x), id(y)
> x == y
> x is y
>
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)
Chris Mellon
> Ben Finney wrote:
> > Chris Carlen <crcarleR...@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".
> 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.
>
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.
Wayne Brehaut
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. ;-)
>>> id(x); id(y)
19105872
19091664
wwwayne
Steve Holden
>>> Chris Carlen <crcarleR...@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.
>>
>
> 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.
>
>>> 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.
>
> 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".
>
global statement allows you to modify a name of module scope from inside
another scope such as a functions.
>
>
>> 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.
>>
>
> 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 -------------
Bruno Desthuilliers
(snip)
>
> 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".
Wildemar Wildenburger
>> (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)
Weeeell, as long as we are nitpicking: That's a tuple, not a list.
;)
/W
Gabriel Genellina
<crcarleR...@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.
--
Gabriel Genellina
Ben Finney
> 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
Wayne Brehaut
Yeah, just wanted to see if you'd catch it!
w
>;)
>/W