Returning none

[C.Laurence Gonsalves]

On Thu, 26 Aug 1999 17:07:43 GMT, Kris J. Zaragoza
<kzaragoza at mediaone.net> wrote:
> 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?
> ...
> 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.

The same could be said about many things that Python currently does
treat as errors. If I pass one parameter to a function that wants two,
is it my fault for leaving out a parameter, or the function's fault for
requiring it. Either way, Python assumes the caller is at fault. If I
wrote the function, and it's really the function that's at fault, I'll
realize that its definition should change, not the call.

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

It isn't intractable, unless you're trying to figure it out at compile
time.

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

I frequently run into this same problem. Something I often do is write
functions that build up a result, and then I forget to return it. ie:

# Yes, I know there's a much easier way to do this. It's just for
# illustration...
def seqToString( seq ):
    result = '['
    if len(seq)>0:
        result = result + repr(seq[0])
        for item in seq[1:]:
            result = result + ', ' + repr(item)
    result = result + ']'


It's quite easy to go to all of the trouble of creating a result, and
then forget to return it. Later, when I call the above function, I get
back "None". If it instead raised an exception when I called it and
attempted to get a result from it, then these errors would be much
easier to catch.

Personally, I think falling out of functions and expecting None to be
implicitly returned is a very Perl-ish thing to do... Why don't we add
$_ to Python as well? I don't think it's too hard to explicitly return
None when that's what you want to do, and I would think/hope that most
existing Python code does this already.

It is possible, but more complicated, to make this a compile time error.
This would essentially require a function/procedure distinction with
restrictions about how you used return in each one. There would still
have to be a runtime error for cases where someone tried to get a result
from a procedure, but cases like the above example could be caught at
compile-time. (The above, being a function, must return a value.
Procedures would have to defined in some other way, like using some new
keyword "proc" in place of "def")

-- 
  C. Laurence Gonsalves            "Any sufficiently advanced
  clgonsal at kami.com                 technology is indistinguishable
  http://www.cryogen.com/clgonsal/  from magic." -- Arthur C. Clarke