Understanding python functions - Instant Python tutorial

[Chris Carlen]

Hi:

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_lis t):
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&Electroni cs Technologist
Sandia National Laboratories CA USA
cr************* **@BOGUSsandia. gov
NOTE, delete texts: "RemoveThis " and
"BOGUS" from email address to reply.

[Gabriel Genellina]

En Thu, 12 Jul 2007 21:51:08 -0300, Chris Carlen
<cr************ ***@BOGUSsandia .govescribió:

Hi:

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_lis t):
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?

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]

Chris Carlen <cr************ ***@BOGUSsandia .govwrites:

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]

Gabriel Genellina wrote:

En Thu, 12 Jul 2007 21:51:08 -0300, Chris Carlen
<cr************ ***@BOGUSsandia .govescribió:

>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.

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.

--
Good day!

_______________ _______________ __________
Christopher R. Carlen
Principal Laser&Electroni cs Technologist
Sandia National Laboratories CA USA
cr************* **@BOGUSsandia. gov
NOTE, delete texts: "RemoveThis " and
"BOGUS" from email address to reply.

[Chris Carlen]

Ben Finney wrote:

Chris Carlen <cr************ ***@BOGUSsandia .govwrites:

def change(some_lis t):
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&Electroni cs Technologist
Sandia National Laboratories CA USA
cr************* **@BOGUSsandia. gov
NOTE, delete texts: "RemoveThis " and
"BOGUS" from email address to reply.

[Wildemar Wildenburger]

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)

[Chris Mellon]

On 7/13/07, Chris Carlen <cr************ ***@bogussandia .govwrote:

Ben Finney wrote:

Chris Carlen <cr************ ***@BOGUSsandia .govwrites:

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]

On Fri, 13 Jul 2007 18:49:06 +0200, Wildemar Wildenburger
<wi******@freak mail.dewrote:

>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. ;-)

>>id(x); id(y)

19105872
19091664

wwwayne

[Steve Holden]

Chris Mellon wrote:

On 7/13/07, Chris Carlen <cr************ ***@bogussandia .govwrote:

>Ben Finney wrote:

>>Chris Carlen <cr************ ***@BOGUSsandia .govwrites:

>>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 oversimplificat ion. First, the
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 [phone] [phone]
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]

Chris Carlen a écrit :
(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".