Understanding python functions - Instant Python tutorial

Chris Mellon arkanes at gmail.com
Fri Jul 13 13:39:19 EDT 2007


On 7/13/07, Chris Carlen <crcarleRemoveThis at bogussandia.gov> wrote:
> Ben Finney wrote:
> > Chris Carlen <crcarleRemoveThis at 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.



More information about the Python-list mailing list