Returning none

[C.Laurence Gonsalves]

On Fri, 03 Sep 1999 15:28:01 GMT, Michael P. Reilly <arcege at shore.net> wrote:
> Me too on the "this looks like a job for...".  Lint programs are made
> for programmers who forget things (like forgetting this is Python and
> not P***) - just about every programmer forgets something.  Changing
> the language with no real gain is not the answer..  there's loss of
> functionality by making functions act like procedures and raise
> exceptions if they aren't.

Lint programs can't do these kinds of checks, and there's no loss of
functionality. If you need to return None, then just say "return None".

> One powerful, often used construct is treating callables as first
> class: does the callable return a value? That doesn't matter, the
> interface needs to be consistant to work properly, and currently it
> does.  

And it still would, with what I proposed.

> Do we now have new functions for apply, map, filter to handle
> "procedures"?  (Are these now procedures?)  

Just to make sure we're talking about the same thing, I've basically
given up on the compile-time distinction between functions and
procedures. 

All I'm proposing now is that functions that don't explicitly return
*something* should return *nothing*, and that calling a function that
returns nothing should cause an exception to be raised. (There's also
the thing about expressioms no longer being a type of statement, instead
function calls would be. This actually would be a compile time
difference, but shouldn't cause any real problems.)

The new implementation of apply would be something like:

def new_apply( f, a ):
    try:
        result = old_apply( f, a )
    except NoResultError:
        return
    else:
        return result

Note that apply will return nothing iff the passed-in function returns
nothing.

map and filter don't make any sense to use for things that return no
result. There could perhaps be a new 'forall' procedure that is
something like map but returns no result. If you're using map for this
purpose now, all I can say is "ewww". Using a for loop is a lot more
efficient than creating big lists full of None I'll bet...

> You then have to know ahead of time if the callable is a function or a
> "procedure".  You can't mix at a non-predetermined point, functions
> and "procedures".  This just adds to the complexity of the language
> and implementations needlessly, removing important functionality.

You *could* use a function that returns nothing in an expression. You'd
just have to catch the exception and do the right thing at that point.
No functionality is lost. Some functionality you'll hardly ever use
(apply is the only example I've seen so far) is just a *tiny* bit harder
to get at. This is functionality most people won't need to get at in
their own functions, so the slight inconvenience in those rare occasions
should be more than made up for by the benefits of the additional error
checking.

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