return None

[Christopher Subich]

Grant Edwards wrote:
> Personally, I don't really like the idea that falling off the
> botton of a function implicitly returns None.  It's just not
> explicit enough for me.  My preference would be that if the
> function didn't execute a "return" statement, then it didn't
> return anyting and attempting to use a return value would be an
> error.

This is a bad idea.  Classically, distinguishing between functions that 
return things and functions that don't return things explicitly divides 
the "callable object" space.  From my CS101 class with its incredibly 
exciting dive into the world of useless pseudocode, callables that 
returned things were called 'functions' and callables that didn't were 
called 'procedures'.

Some languages do make this distinction; QBASIC, for example, had 
'gosub' separate from function calls.

What do you do for an early break from a function that still returns 
not-even-None [ReallyNone], "return?"  That looks and acts like a 'real' 
return statement, and the distinction between 
return-without-a-value-so-maybe-except and return-with-a-value is 
suddenly magnified to real importance.

Further, and I consider this a truly damning case, look at decorater.  A 
naive "logging" decorator could be defined like this:

def logger(func):
    def new_func(*args, **kwargs):
       print '%s called with:' % func.__name__, args, kwargs
       retval = func(*args,**kwargs)
       print '%s returns:', retval
       return retval
    return new_func

This logger works without modification for both value and non-value 
returning functions.  Its output isn't quite as pretty for non-value 
functions, but it works and the implementation is both simple and flexible.

With a function-schism, to keep its simple implementation 'logger' would 
have to be rewritten as 'flogger' (same as current-logger, for use on 
functions), and 'plogger' (for use on procedures).  The downside here is 
that if the function/method changed to or from a procedure, the 
decorator would have to be switched.

Alternatively, the logger decorator could be longer and explicitly catch 
the possible exception.  But why should we have to write like that, for 
a use-case that doesn't even represent a true error -- arguably not even 
an exceptional case?  Python's definitely not a B&D language, talk of 
floggers aside.