On Dec 29, 8:26 pm, Bruno Desthuilliers <bruno. 42.desthuilli...@websiteburo.invalid> wrote: > John Machin a écrit : > > > > > On Dec 29, 7:06 am, Roger <rdcol...@gmail.com> wrote: > >>> 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 > >> To me this is the soundest argument. Thanks for the advice. I think > >> I'll follow this as a rule of thumb hereafter. > > > Please don't. Follow MRAB's advice, with the corollary that a > > generator is forced by the compiler to be a "procedure" in MRAB's > > terminology. > > I fail to see any *practical* difference between MRAB's and Steven's > POVs. In both cases, it boils down to > - don't use a bare return at the end of a def statement's body, > - either use only bare returns ('procedure') or explicitely return None > ('function')
Steven's treatment was somewhat discursive, and didn't explicitly mention the 'procedure' possibility. In fact, this sentence "if you have a function with early exits, and you need to make the intent of the function clear, explicitly return None." would if applied to a 'procedure' cause a stylistic horror as bad as a bare return at the end of the def. -- http://mail.python.org/mailman/listinfo/python-list