Handle empty function bodies safely

[JukkaL]

Currently an empty function body is accepted if a function returns a non-None value (even with --strict-optional). This is mostly useful for abstract methods. This is unsound, since we don't prevent anybody from calling these empty functions.

Here are some ideas for making this safe:

• Only allow empty function bodies for abstract methods. Other functions will need something like a return statement, a raise statement or assert False or # type: ignore.
• Tag abstract methods with an empty body with a flag in the AST, and disallow calls to them via super().

This still wouldn't address empty functions defined in stubs, but perhaps can just assume that every function in a stub has a non-empty body.

See also discussion in #2339.

[gvanrossum]

This would only apply to abstract methods whose return value cannot be None, right? I think this should be okay and allowed via super:

class C:
    @abstractmethod
    def f(self) -> Optional[int]:
        pass
class D(C):
    def f(self) -> Optional[int]:
        return super().f()

[JukkaL]

Yeah, we could safely allow those examples.

[rwbarton]

The extensive use of functions with empty body and arbitrary type in the tests was another motivation for allowing empty bodies. Though it isn't a problem now, there would be a huge pain should warn-no-return (and perhaps strict-optional) be turned on by default. Not saying it should block this change, but it would be good to have some plan for dealing with this when it comes up.

[gvanrossum]

I think @ddfisher would like both of these to become the default. David, can you come up with a plan?

[ddfisher]

I think it'd be reasonable not to worry about this too much for now: we're erring on the side of being more permissive (which is the better side to err on when introducing a new default), and I'd expect empty functions to be much more often intentional than not.