On Sunday, October 26, 2014 7:11:43 PM UTC+5:30, Dan Sommers wrote: > At one time, on a huge project, millions of lines of C and assembly > code, we had a local guideline *not* to write void functions. The idea > was to return something that might be useful later, even if it seemed > unlikely now. A simple success flag was sufficient; as functions grew, > often did their failure modes.
Well C and Python are completely different in this respect. In C it is the norm to return the status in the return value and the actual return value in pointer parameters. Or even worse in pointer parameters + globals: think of most of the system calls and errno. This low-level messiness is in fact one of the compulsions that have driven preference and development of higher level languages like python. Here failure-mode has dedicated syntax -- exceptions. This conduces to a more DRY, less error-prone setup. - Normal mode in the normal functional call-return style - Failure mode in the except (for caller); raise (for callee) clauses. Note that my comment was: > Its generally accepted that side-effecting functions are not a good idea > -- typically a function that returns something and changes global state. So I am not talking of merely global (or non-local) variable side-effecting functions/methods which is normal in imperative programming, but ones that do BOTH - both changing global state - returning useful results in the return value While this may be called a code-smell, in C like languages it is close to unavoidable. In python its more avoidable and therefore more smelly (to my nose at least!) Yeah I note Terry's examples of list.pop etc. I guess one could say that these are instances of practicality beats purity. However note the context where this thread arose. A beginning programmer having a hard time distinguishing: - Values and effects - Expressions and statements - Immutable and mutable data-structures - Functions and Procedures My claim is that until then, he should not be trying to write code like that. -- https://mail.python.org/mailman/listinfo/python-list
