Implicit Returns

00:00 Python automatically adds implicit return statements to the end of any function that you’ll write. So therefore, if a function does not specify a return value, it will return None by default. And I know this can be a little bit confusing, so with this video tutorial, you’re going to learn exactly how these implicit return statements work and how you can use them to your advantage.

00:20 And then, of course, also how you’re going to be able to see how they work in other people’s code, which is really important for understanding the Python code that’s out there.

00:29 Okay. So, let’s start with a simple example. I’ve got this dummy function here, and it just contains a simple if statement here. And what you can see here in the last line, it actually returns a None.

00:43 And now, with the implicit returns feature in Python you can simplify this function. So, let me show you a new version of this function that will be exactly equivalent—so it would lead to the same output—but it doesn’t actually return None here.

01:00 It’s just a bare return statement, and a bare return statement in Python implies that None will be returned. You might use that in some cases to simplify your code a little bit. It could also be confusing if someone doesn’t know about this feature, so that’s always something to keep in mind. Now, because the return statement is implicit, that means you can actually leave it out completely.

01:20 So, that’s what I’m doing here in this foo3() function. In this case, I’m leaving out the return statement in the else part of that if statement, and this will lead to exactly the same result.

01:32 So, all of these functions are exactly equivalent. They have the exact same return values, but you can see here that this last option is quite a bit shorter and easier to read than the first one.

01:45 But just to confirm that they actually all have the same output, let’s actually run them. So, what I’m going to do here is I’m going to go through each of those functions and I’m going to call them with an argument of False, which is going to trigger the else branch in the central if statement, here.

02:02 And we should expect to always get a None return value, here. So let’s try it with the foo1() function, which is just kind of the unchanged version of that function—the original version of that function. So, all right, this returned None.

02:17 Now, let’s try it with the bare return statement that would also imply return None. And again, this returns None as well.

02:25 And now let’s try it with the third function, the foo3() function here, that doesn’t include the else branch altogether. It only has the truthy branch here, and there’s no return statement whatsoever.

02:39 Once I run this, you can see here, it also returns None. And if I pass a truthy argument, you can see here that it correctly returns the actual value. So, if I pass something else, it’ll just bounce that back to me. And yeah, I guess this is proof that this really works and I’m not just making this stuff up. Now, of course, the question that remains is, “When should you actually use this?

03:06 When is it a good idea to use this feature in your own Python code?” So, my rule of thumb is if a function does not have a return value—so in other languages, that will be called a procedure—then I always leave out the return statement.

03:19 So, I don’t add empty return statements if I don’t have any sensible value to return. Right? So for example, if I wrote something like the built-in print() function—that would only ever be called for its side effects, it would never return anything—then I wouldn’t put a return statement there.

03:35 It just wouldn’t make any sense in my mind. If you’re following that principle, the only time you need to decide whether or not to use a implicit return None statement is when a function actually has a return value that makes sense from a logical perspective, right? So, the print() function—we’re only calling it for its side effects. But the sum() function, for example—we want to call that because we expect some kind of return value. With a function like that, where it would logically make sense for it to return None, I think that’s where we need to discuss whether or not you should use an implicit or an explicit return None statement. And I think on the one hand, you could say that, “Well, if you leave out the return None statement, it makes the code more concise and therefore easier to read and understand,” and maybe you could say makes it prettier. On the other hand, this feature—it might really surprise some programmers, and they might not know that Python behaves that way. When it comes to writing clean and maintainable code, then using this surprising behavior is usually not the best way to go about it.

04:32 For example, the book that I’m working on, I had a couple of code examples there—or, I think I had one code example there that was using an implicit return None statement, and so I started getting these regular emails where people mentioned that, “Hey Dan, you’re missing a return statement here.” And I have this almost, like, this template saved away that I would send people as a reply, I was like, “Hey, you know what?

04:58 Python actually does these implicit return statements, and that’s totally okay, but I can see why it’s confusing.” And so my thinking there has shifted a bit where I’m thinking—you know, in this case, in the book, I actually changed it because the point of that code example wasn’t about the missing return statement or being concise, but it was more about something else entirely, and being very clear and making the example very easy to understand. So in this case, I think it made sense to bring back the explicit return statement. I mean, don’t get me wrong—I love writing clean and beautiful code as much as anyone else, and I used to feel really strongly that programmers should really know the ins and outs of the language they’re working with. But also, you gotta be realistic about this stuff, right?

05:39 So, when you consider the maintenance impact of even a simple misunderstanding where you’re working in a bigger team and there’s this back and forth on, “Oh, hey, are we missing a return statement here?” “Ah, no, I guess there’s this, like, rule in Python that you can leave it out.” And then, you know, someone is asking about that in chat, or maybe someone is tapping you on the shoulder, so that causes an interruption—and it just, you know, it’s like the butterfly effect where you have this little thing and it just kind of spirals out of control, and it has a much larger impact than you would have thought it would have initially.

06:14 And so I think when you consider the maintenance impact of stuff like that, then I would be leaning more towards making the code explicit and very clear.

06:24 So, I’m not going to make a definite recommendation here, or like a definitive recommendation where I’m going to say, “Hey, you always have to use this feature,” or, “You should never use this feature.” It always depends. So honestly, it really depends on the circumstances, but personally, I try to keep in mind that code is communication, and it is meant primarily for humans—not for computers, otherwise we would all be writing some kind of binary, bytecode assembler language, or something like that.

06:56 Right? We wouldn’t be writing Python. So, I always try to err on the side of being more explicit so that people have an easier time understanding and maintaining my code. So, you know, that might not be your philosophy, but I think it really helps in making it easier to work with other people and also making your programs more maintainable in the long run. All right.

07:18 I know I’m kind of leaving you alone here with making this decision, but try it out. Be aware that this exists and implicit return values are a thing in Python because they’re going to come in handy and you’re going to encounter them, but also balance it with the need for being clear and writing maintainable code.