Returning none

[Skip Montanaro]

    G> So put me firmly in the camp that favors a stronger PyLint (I just
    G> recently got bit by a rarely used bare return in some released code).

    C> This is akin to saying array-bounds checking should be done by PyLint
    C> rather than the runtime. The problem is, a lot of these checks simply
    C> can't be done statically.

I'll assert here without proof that the primary mistake programmers are
likely to make in this regard is to include both "return <some value>" and
"return" (or the terminating byte code) in the same function.  This sort of
error a program like PyLint could indeed check.  There's be no need to add
the overhead of checking for incorrect function/procedure return semantics
at run-time.

    C> In fact, while I was originally proposing some compile-time checks as
    C> well, I've basically given up on those. They were mostly incomplete
    C> (Python is too dynamic to be able to do much static checking in this
    C> situation) and Tim found a real problem with them.

Perhaps I missed something (this thread is getting rather long and drawn
out).  What sort of situation would PyLint miss that my proposed static
check wouldn't catch?

Skip Montanaro | http://www.mojam.com/
skip at mojam.com | http://www.musi-cal.com/~skip/
847-971-7098   | Python: Programming the way Guido indented...