5.3: Return Values

Okay, you’ve been in suspense long enough. Time for the bomb.

First, we’re going to add another phrase to our already lengthy function-calling mantra. You’ll recall that we summarized this code (a function call):

Code \(\PageIndex{1}\) (Python):

len(movie_title)

with this English:

“We are calling the len() function, and passing it movie_title as an argument.”

And we summarized this code (a method call):

Code \(\PageIndex{2}\) (Python):

message.format(name, age)

with this English:

“We are calling the .format() method on the message variable, and passing it name and age as arguments.”

Now, a third thing. We can use the equals sign with a variable name to capture the output of the function or method, instead of just printing it. The output of a function is called its return value. We say that “the .upper() method returns an upper-case version of the string it was called on.” We can capture it like this:

Code \(\PageIndex{3}\) (Python):

big_and_loud = shop_title.upper()

The variable big_and_loud now holds the value "CARL'S ICE CREAM".

Functions work similarly:

Code \(\PageIndex{4}\) (Python):

width_of_sign = len(shop_title)

The width_of_sign int now has the value 40 (remember all those extraneous spaces); if we’d trimmed first, we’d have gotten 16:

Code \(\PageIndex{5}\) (Python):

true_width_of_sign = len(shop_title.strip())

print(true_width_of_sign)

The Bomb

I’ve probably built this up too much, but I think you’ll agree that the following output is pretty surprising:

Code \(\PageIndex{6}\) (Python):

diva = "Ariana Grande"

diva.upper()

print("I just love {}!".format(diva))

| I just love Ariana Grande!

Wait...did the “diva.upper()” part just not work? Did it get skipped? Did we do it wrong somehow?

Even more confusing, putting the “.upper()” call directly in the print statement seems to work...but only temporarily. Accessing diva a moment later appears to revert it back to its old value:

Code \(\PageIndex{7}\) (Python):

diva = "Ariana Grande"

print("I just love {}!".format(diva.upper()))

print("When does the next {} album come out?".format(diva))

| I just love ARIANA GRANDE!

| When does the next Ariana Grande album come out?

The root cause of this and practically all perplexing Python printing can be discovered by consulting the memory picture. Here’s how it starts out when we first define diva:

Now say we do this:

Code \(\PageIndex{8}\) (Python):

new_var_name = diva.upper()

The result is this picture:

And now we see the reason for it all. The contents of the diva variable itself are unchanged by the method call. Calling “.upper()” on diva didn’t change the string value in diva: it merely returned a modified copy of the string.

Think of it this way: if I asked you, “what is your name in Pig Latin?” and you told me, that would not intrinsically change your actual name to be in Pig Latin. You would simply be “returning” to me the Pig Latin version of it in response to my query.

You could argue this behavior of Python’s is dumb, or at best misleading, and I’m actually inclined to agree with you in this case. But of course beggars can’t be choosers: someone took the time to write the .upper() method for us, so if we want to take advantage of it we have to use his/her owner’s manual. And the fact is that many (perhaps even most) Python functions/methods – including many of the ones from Pandas, which we’ll use extensively – are coded with this style: not actually modifying the variables they are passed, but instead returning to you a modified copy which you must store.

Now given that this is the case, it would at least be nice if I could tell you that it always, consistently worked this way. Then you could simply accept it and get used to it. Alas, no. There are functions/methods (lots of them) which do modify a parameter or the variable they were called on. So sometimes, our naïve approach of calling the method and expecting the variable to change is exactly what we need to do. The bottom line is: there’s no way of knowing without being told, or else reading the documentation. We’ll learn how to do the latter in a future chapter. For now, I’m simply telling you for the record that the methods in Figure 5.2.1 are all of the “return a modified copy” type, and giving you a heads up that both styles of method do exist out there in abundance.

A couple more things. First, as a corollary of the above, realize that the following statement (on a line by itself) is officially 100% useless:

Code \(\PageIndex{9}\) (Python):

name_of_pet.lstrip()

You called the .lstrip() method, and then....did nothing with the return value. If you don’t store it in a variable – or else do something with it right away like print it before it slips out of your fingers – it’s irrevocably lost: it doesn’t even show up on the memory picture because there’s no variable name. (Think about that.)

Second, note the following pattern which is very often used:

Code \(\PageIndex{10}\) (Python):

name_of_pet = name_of_pet.lstrip()

Here, we’re calling .lstrip() on the name_of_pet variable and then storing the return value back in the name_of_pet variable. This might be what you thought would have happened in the first place – the author of the previous, useless line, probably wanted the variable itself to permanently have its leading spaces removed. Simply calling .lstrip() on the variable won’t do that, but putting the revised value back in the same blue box on the memory diagram will.