"return" in def

[Aaron Brady]

On Dec 28, 11:56 am, Gerard Flanagan <grflana... at gmail.com> wrote:
> On Dec 28, 5:19 pm, Roger <rdcol... at gmail.com> wrote:
>
> > Hi Everyone,
> [...]
> > 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 not particularly excessive but it is uncommon. A nekkid return
> can sometimes be essential within a function body, so a non-essential
> nekkid return could be considered just noise.

One style of coding I heard about once only permits returns at the end
of a function.  It claims it makes it easier to see the function as a
mathematical object.

It's a slick idea, but multiple exit points are really practical.

Incidentally, generators have multiple entry points.  They "yield
multiple times, they have more than one entry point and their
execution can be suspended" -- http://docs.python.org/reference/expressions.html#yield-expressions

The discussion makes me think that 'clear' is subjective, just like
'natural' has 39 definitions.