"return" in def

[John Machin]

On Dec 29, 8:26 pm, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:
> John Machin a écrit :
>
>
>
> > On Dec 29, 7:06 am, Roger <rdcol... at 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.