I know Option B is more efficient because it only declares b() once, and then the variable y is just passed as a context variable. But Option A seems to be simpler syntax, eliminating the need to construct a lambda, and simplifying the interface of b(). Suppose further that there could actually be many context arguments. The complexity blows up on the interface of b():

Care about efficiency when it's on your performance-critical path, and you have profiling results that confirm it. Otherwise, go for simplicity; programmers' time costs much more than CPU time.
– 9000Feb 1 '15 at 19:58

The b in your Option Bs doesn't seem to have much point. Why not just do map (lambda x:x+y1+y2+y3+y4+y5, x) for B2 for instance? In general, I'd only ever use a lambda, or define a function, but never both in conjunction.
– Steven BurnapFeb 1 '15 at 22:05

2 Answers
2

Per the Zen of Python: simple is always better than complex. I'd pick the first option on the principle that it is vastly easier to understand and thus easier to maintain. Generally speaking, in Python, one worries more about the ease of use of the code than the efficiency of the code.

Finally, the least frequently used option is to specify that a function can be called with an arbitrary number of arguments. These arguments will be wrapped up in a tuple (see Tuples and Sequences). Before the variable number of arguments, zero or more normal arguments may occur.

Normally, these variadic arguments will be last in the list of formal parameters, because they scoop up all remaining input arguments that are passed to the function. Any formal parameters which occur after the *args parameter are ‘keyword-only’ arguments, meaning that they can only be used as keywords rather than positional arguments.

Do you need the efficiency more than the simplicity, or the simplicity more than the efficiency?

Use what makes sense for your specific application. If you need the simplicity more than the efficiency, then use option A. If you need the efficiency more than the simplicity, then use option B.

Code profilers can help immensely in this regard. Programmers are notoriously bad at guessing how expensive a given operation is; a code profiler can give you evidence that will help you determine the real cost of a computation, and help you make a better, more informed choice.