Returning none
Skip Montanaro
skip at mojam.com
Fri Sep 3 22:03:13 EDT 1999
>> 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...
More information about the Python-list
mailing list