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. -- http://mail.python.org/mailman/listinfo/python-list