Returning none

[Skip Montanaro]

    >> 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> There's the example I posted, which was something like:

    C>     def seqToString( seq ):
    C>         result = '['
    C>         if len(seq)>0:
    C>             result = '[' + ' ' + repr(seq[0])
    C>             for i in seq[1:]:
    C>                 result = result + ', ' + repr(i) 
    C>         result = result + ']'

    C> PyLint can't catch it, because there's nothing actually wrong with
    C> this function. When I call it like this though:

    C>     a = seqToString( b )

    C> then I've done something wrong. Only runtime checks could catch that.

You are correct, but that's not what I said.  I said having a mix of
"return" and "return expr" in a function *is* catchable at compile time.  I
think it's the most likely mistake to make, not asking for the result of a
function that only returns None.

    C>     def calcStuff(x):
    C>         if isGood(x):
    C>             return x*42;
    C>         else:
    C>             kablowie( "x is bad!" )

    C>     def kablowie(s):
    C>         raise "Argh: " + s

    C> The static checks would incorrectly think calcStuff was inconsistent.
    C> You can't trace into kablowie from calcStuff, because there's no
    C> telling what the value really is at runtime when I call calcStuff.

If Tim gave it as an example, he's probably used it in his own code
somewhere with good reason <wink>, but anybody else caught programming that
way ought to be shot.  A spurious warning from either the compiler or PyLint 
wouldn't be such a bad idea in this case.

    C> When all else is equal, I prefer compile-time checks. This isn't a
    C> situation where they can be very useful though. Even if the language
    C> were changed to allow tagging of functions as "has result" or
    C> "doesn't have result", the "kablowie" problem still exists...

I still believe such checks would be useful even without being able to catch 
every situation all the time.

    C> Returning "nothing", and checking if it is returned into an expression,
    C> seems like the only viable way to check for this type of error. It's
    C> also consistent with the fact that maps and sequences all raise
    C> exceptions when you try to access a nonexistant value. (ie: KeyError or
    C> IndexError)

I guess we're going to have to agree to disagree.  I don't think it's a big
enough problem to warrant changing the language.

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...