Consistent use of "return None" in functions

[gvanrossum]

Could you add this rule to pep8? I just updated the official PEP 8 to include this (I'm surprised it wasn't already there):

• Be consistent in return statements. Either all return statements in a
  function should return an expression, or none of them should. If any return
  statement returns an expression, any return statements where no value is
  returned should explicitly state this as return None, and an explicit
  return statement should be present at the end of the function (if
  reachable).

   Yes:

   def foo(x):
       if x >= 0:
           return math.sqrt(x)
       else:
           return None

   def bar(x):
       if x < 0:
           return None
       return math.sqrt(x)

   No:

   def foo(x):
       if x >= 0:
           return math.sqrt(x)

   def bar(x):
       if x < 0:
           return
       return math.sqrt(x)

https://mail.python.org/pipermail/python-dev/2015-April/139054.html

[IanLee1521]

Thanks, I saw this discussion and this helps remind me to implement it. :)

[asottile]

fwiw, mypy is probably better suited to implement this type of check (and it already does):

import math

def foo(x: float) -> float:
   if x >= 0:
       return math.sqrt(x)

def bar(x: float) -> float:
   if x < 0:
       return
   return math.sqrt(x)

$ mypy --check-untyped-defs t.py
t.py:3: error: Missing return statement
t.py:9: error: Return value expected
Found 2 errors in 1 file (checked 1 source file)

[SylvainDe]

Quite a lot of work has been spent on this issue but not much actual progress what integrated.
Before trying to go further, it may be interesting to have answers for the following questions:

1. do we still want to be handled by the pycodestyle tool ?

2. if so: do we agree that it needs to be an AST-based check ? An alternative could be to perform the check is a slighty weaken form as in Check inconsistent return statements #711 which seems pretty interesting.

3. If so, as far as I can tell: no other check built in pycodestyle is based on AST check which raise various questions:

• should we ignore it by default to keep things fast by default ?

• should we first make sure that AST-based check can be implemented in the code base without much trouble ? (ie: ensuring that all the test suite is valid Python code as much as possible ? also: how to handle tests corresponding to code that is parsed as valid Python code depending on the Python version)

These questions come from discussions over various PRs:

• Add checks for unconsistent returns #431 ( "Add checks for unconsistent returns" )

• Make tested code valid Python code #657 ( "Make tested code valid Python code" )

• [DRAFT] Add support for checks on unconsistent returns #527 ( "[DRAFT] Add support for checks on unconsistent returns" )

• Check inconsistent return statements #711 ("Check inconsistent return statements")

Having gone way too far is the AST check direction, I can see the troubles it leads to and think it may be just easier to consider that #711 is probably as good as things can be.

[sigmavirus24]

I, for one, am of the mind that people should be using pylint in addition to flake8 and other tools. In light of the fact that pylint has support for this, is there urgency in us figuring out the right way to do this? For one thing, I'd rather as few false positives as possible. I wonder if, because this is an AST concern, if we can just write this as something that acts as an AST plugin for Flake8 (maybe one already exists?)