Returning none

[Kris J. Zaragoza]

On Thu, 26 Aug 1999 14:33:40 GMT, Paul Prescod <paul at prescod.net> wrote:
>I think it would be more pythonish if this would return a runtime (or
>even compiletime) error:
>
>def foo():
>	a=5
>
>b=foo()
>
>It shouldn't just return None. That's a source of errors.

The question here is, where is the error?  Unlike Basic (VB,
LotusScript, etc.), Python does not differentiate between blocks that
return a value (a Function), and those that do not (a Sub).  This
means that the above function foo() is, as defined, syntactically
correct.

Now when the call is made, you need to make a determination as to
whether the calling line is in error, or the function itself is in
error.  With your example, it could be either.  The author of the
function may have erred in neglecting to insert a return statement at
the end of the function.  If, on the other hand, the function does not 
intend to return any values, then the author of the calling line made
the error in simply assuming that it would.

I tend to like Python's current way of handling things.  If a function 
does not explicitly return a value, None is returned instead.  It's a
clean solution to an otherwise intractable problem.

How do you propose fixing this in Python 2?  Would you enforce the
separation of blocks that do and don't return values?  Would you
include some sort of pragmas that tell the compiler and runtime that a 
value is not to be returned?  Other ideas?  (Personally, I wouldn't
mind if this stayed as is.  I just read the documentation or doc
string to see if a given function is meant to return a value.)

-Kris

-- 
Kris J. Zaragoza           | "Unfortunately, most people can't out-think a
kzaragoza at mediaone.net     | grapefruit."  --Jon Bodner