### CS150 - Fall 2013 - Class 11

• exercises

• objects
- Almost everything in Python is actually an object!
- ints, floats, bools, etc.
- what does this mean?
- they have data
- they also have methods

>>> x = -10
>>> x.bit_length()
4
>>> x.__abs__()
10
>>> (-10).__abs__() # we need parenthesis to avoid confusion with floating point numbers
10

- We can see all the methods associated with an object using "help" just like we did for functions
- for ints

>>> help(int)

gives all of the methods that can be called on an int object

>>> x = 10
>>> help(x)

- for strings

>>> help(str)

• references
- objects reside in memory
- anytime we create a new int, float, string, list, etc. it is allocated in memory

- variables are references to objects in memory
- a variable does NOT hold the value itself, but it is a references to where that values resides
- arm/hand metaphor
- think of variables like your hands
- you can point them at things and then ask questions:
- what is the name of the thing that my right hand points to?
- for the thing that my left hand points to, do something?
- you can point them to new things (i.e. assignment)
- you can point point them at the same thing (i.e. assignment one to the other)
- but they are separate things!
- similarly, variables are separate things
- they can reference the same thing, but they are not the same thing

- when you ask for the value of a variable, it's actually getting the value of the things it references in memory

• = (i.e. assignment)
- when we say x = y what we're actually saying is let x reference the same thing that y references
- x and y are still separate variables
- if we say x = z that does NOT change the value of y

• mutable objects
- if an object is mutable (i.e. it has methods that change the object) then we have to be careful when we have multiple things referencing the same object (this is called "aliasing")

>>> x = [1, 2, 3, 4, 5]
>>> y = x

- what does this look like in memory?
- there is one list object
- both x and y are references to that same object (drawn as arrows in class)

- what happens when I call a method that changes/mutates the object?

>>> y.reverse()
>>> y
[5, 4, 3, 2, 1]
>>> x
[5, 4, 3, 2, 1]

x and y are references to the same object!

>>> x[0] = 0
>>> x
[0, 4, 3, 2, 1]
>>> y
[0, 4, 3, 2, 1]

statements that mutate the object that are done on either variable will affect this object

>>> y[0] = 15
>>> x
[15, 4, 3, 2, 1]
>>> y
[15, 4, 3, 2, 1]

- If we change what one of them references using assignment, then it will NOT affect the original object
>>> y = [0] * 5
>>> y
[0, 0, 0, 0, 0]
>>> x
[0, 4, 3, 2, 1]

there are now two separate objects and x and y each reference a different object

- why hasn't this problem come up with ints/floats/bools/strings? We said they're objects?
>>> x = 10
>>> y = x

- what does the memory picture look like?
- we just have one int object!
- x and y are both references to that one int object
- it seems like we could have the same problem as with lists...
- ints/floats/bools/strings are not mutable!
- there is no way for us to change the underlying object
- therefore, even though two variables reference the same int, it's as if they referenced separate ints
- draw the memory picture for the following:

>>> x = 10
>>> y = x
>>> y = 15
>>> x
10
>>> y
15

- we now have 2 objects (10 and 15)
- just like with lists, changing what y references does not affect x

• parameter passing and references
- some terminology:
- when we define a functions parameters we are defining the "formal parameters"

def my_function(a, b):
return a+b

- a and b are formal parameters
- until the function is actually called, they don't represent actual values
- when we call a function, the values that we give to the function are called the "actual parameters" (sometimes also called the arguments)

>>> x = 10
>>> y = 20
>>> my_function(x, y)
30

- the values 10 and 20 are the actual parameters (or similarly, x and y become the actual parameters)

- when a function is called the following happens:
- the values of the actual parameters are determined (we evaluate the expression representing each parameter)
- the value is just an object (could be an int, float, string, etc)
- these values are then "bound" or assigned to the formal parameters
- it's very similar to assignment
- the formal parameters represent new variables
- the formal parameters will then REFERENCE the same objects as those passed in through the actual parameters

- let's consider the picture for our function above
- x and y are both references to int objects
- when we call my_function, the formal parameters a and b, will represent two new variables
- these variables will reference the same thing as their actual parameters
- think of it like running the statements:
a = x
b = y

- a will reference the same thing as x
- b will reference the same thing as y

- for non-mutable objects, this whole story doesn't really matter. Why?
- they could be references to the same thing or copies, if we can't mutate the object, the behavior is the same
- how does this change for mutable objects?

def changer(a):
a[0] = 100

>>> x = [1, 2, 3, 4, 5]
>>> changer(x)

- what does the picture look like for this function call?
- x was a variable that references a list object
- when the function was called, the formal parameter a will represent a new variable
- a will reference the same thing as x
- think of it like running the statement
a = x
- because the object is mutable and since the formal parameter references the same object as what was passed in, changes made to the object referenced by a will also be seen in x
- notice, however, that operations that do not change/mutate the object will NOT be seen outside the function
def no_changer(a):
a = [0]*5

>>> x = [1, 2, 3, 4, 5]
>>> no_changer(x)

- in this case, we're assigning a to some new object
- we can't change what x references!
- x and a will no longer reference the same object
- any changes to a after this will not affect x

• why is variable assignment and parameter passing done based on the references (i.e. a shallow copy) rather than a deep copy of the whole object?
- performance (it takes work to copy the object)
- often we just want the value and don't need to mutate the underlying object

• slicing revisited
- what does slicing do with respect to objects?
>>> x = [1, 2, 3, 4, 5]
>>> y = x[0:2]
>>> y
[1, 2]
>>> y[0] = 100
>>> x
[1, 2, 3, 4, 5]

- what does this say that slicing does?
- slicing creates a new list object

- given this, how could we create a deep copy of other_list?
>>> my_list = [1, 2, 3, 4, 5]
>>> other_list = my_list[:]
>>> other_list[3] = 100
>>> other_list
[1, 2, 3, 100, 5]
>>> my_list
[1, 2, 3, 4, 5]

- besides accessing a slice, we can also assign to a slice
>>> x = [1, 2, 3, 4]
>>> y = [5, 6, 7, 8]
>>> x[0:2] = y[0:2]
>>> x
[5, 6, 3, 4]
>>> y
[5, 6, 7, 8]

- slicing creates a new list, so there is no sharing
>>> x[0] = 100
>>> x
[100, 6, 3, 4]
>>> y
[5, 6, 7, 8]

- in fact, we can slip in a larger slice if we'd like
>>> x = [1, 2, 3, 4]
>>> y = [5, 6, 7, 8]
>>> x[0:2] = y[0:4]
>>> x
[5, 6, 7, 8, 3, 4]
>>> y
[5, 6, 7, 8]

- be careful, though... assigning to a slice is different than assigning to an index
>>> x = [1, 2, 3, 4]
>>> y = [5, 6, 7, 8]
>>> x[0] = y[0:2]
>>> x
[[5, 6], 2, 3, 4]

• swap
- given the following function:

def swap(a, b):
temp = a
a = b
b = temp

- what would be in x and y after the following statements:
>>> x = 10
>>> y = 20
>>> swap(x, y)