On Mar 15, 1:01 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > On Fri, 14 Mar 2008 11:32:41 -0700, Lie wrote: > > No, there is no need for "void" return type, what I meant is that > > everything that's not said in the documentation should be assumed to > > be an implementation detail, a method or a function that doesn't say > > anything about its return type should be assumed to return an > > implementation detail (which basically means: Don't rely on this). The > > fact that list.append returns none is just a coincidence, you might > > encounter another list.append that returns different thing some time > > in the future, or the far future, or perhaps at the end of the > > galaxy's life. > > I expect functions with no documentation of what they return to return > `None`. Assuming they are documented at all, of course. :-) > > It's like not writing a ``return`` statement in the code: there's always an > implicit ``return None`` at the end of every function.
I personally won't to rely on it. Sometimes a return statement might be documented, but not complete enough, like this: def genericadd(a, b): """ Adds two number, returns the same as longadd if either operands are long type and returns the same as intadd if all operands are int type. <ommiting documentation about what would happen if either type are neither long nor int by negligence> """ if isinstance(a, long) or isinstance(b, long): return longadd(a, b) if isinstance(a, int) and isinstance(b, int): return intadd(a, b) return "Error" This function is written badly on purpose to simulate what a less-than- intelligent programmer might write, which is in no control of ours as a class user. -- http://mail.python.org/mailman/listinfo/python-list