On Sun, 28 Dec 2008 12:38:50 -0500, Steve Holden wrote: > Roger wrote: >> Hi Everyone, >> >> First I want to thank everyone that posts to this group. I read it >> daily and always learn something new even if I never feel like I have >> anything to contribute but my questions. >> >> When I define a method I always include a return statement out of habit >> even if I don't return anything explicitly: >> >> def something(): >> # do something >> return >> >> Is this pythonic or excessive? Is this an unnecessary affectation that >> only adds clock ticks to my app and would I be better off removing >> "returns" where nothing is returned or is it common practice to have >> returns. >> > It's an unnecessary affectation, but I don't believe it adds any clock > ticks to your app, as the function has to return anyway. The dis module > shows you they both generate exactly the same code: ... >> Even when I'm not explicitly returning something I like to add "return" >> because it's a good additional visual marker for me to see where a >> method definition ends especially in cases where I may use a nested >> method. >> > Well, I suppose at least you aren't writing "return None" ... Normally a > blank line or two suffices for me.
Curious. When I see a bare return, the first thing I think is that the author forgot to include the return value and that it's a bug. The second thing I think is that maybe the function is a generator, and so I look for a yield. If I don't see a yield, I go back to thinking they've left out the return value, and have to spend time trying to understand the function in order to determine whether that is the case or not. In other words, even though it is perfectly valid Python, bare returns always make the intent of the function less clear for me. I'm with Bruno -- if you have a function with early exits, and you need to make the intent of the function clear, explicitly return None. Otherwise, leave it out altogether. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
