4 ms·
Please use def over lambda when feasible (which is most of the time); using lambda needlessly hurts debugability and saves a total of three characters. def
by Veedrac 9y ago
Please use def over lambda when feasible (which is most of the time); using lambda needlessly hurts debugability and saves a total of three characters.
def even(x): return x % 2 == 0
- flavio81 9y agoYes but lambda allows some versatility, for example (excuse my Python, it is a bit rusty): formulas = { 'sum': lambda x,y: x+y, 'subst': lambda x,y: x-y, 'mult': lambda x,y: x*y, 'pow': lambda x,y: x**y } def apply_operator(operation_name, x, y): operation=formulas[operation_name] return operation(x,y) Using "def"s there would kill readability and easiness of coding.
- tobik 9y agoBad example :) Most simple uses of lambda like this can be substituted with functions from the operator module: import operator formulas = { 'sum': operator.add, 'subst': operator.sub, 'mult': operator.mul, 'pow': operator.pow }
- flavio81 9y agoI thank you for this example. If the operator definitions are not trivial and you want to keep them well mantained, then your example is very good. However, what I meant was that for fast, quick coding, if your 'operator' function is really simple, then lambda fints perfectlu. I know the Zen of Python says: "There should be one—and preferably only one—obvious way to do it", but i don't align to that principle. I think there should be more than one way to do something, and one should choose one that fits the best.
- owebmaster 9y agoIt is not about char length. The first is an expression while the second is a statement. I find it easy to debug code with expressions rather than statements, could you clarify why the first way would be worse for debugability?
- Veedrac 9y agoThe only meaningful difference between the two is that the lambda is named <lambda> and the function is named even. I'm happy for you to use lambdas in an expression context, if that's how you like to roll, but assignment is a statement anyway, so it doesn't matter there and you might as well choose the one that produces helpful tracebacks.
- eriknstr 9y agoFurthermore I would prefer def even(x): return not(x % 2)
- scott_s 9y agoI would not. That's incidentally depending on non-zero numbers to become True, and zero to become False. I would prefer to think of the operation as "is x modded by 2 equal to zero?" rather than "does x modded by 2 become true when negated?"
- Veedrac 9y agoThough you might find core developers disagreeing with that sentiment. https://stackoverflow.com/a/3175293/1763356 https://stackoverflow.com/a/3175293/1763356
- scott_s 9y agoI do find it interesting, but it doesn't change what's easier for me to reason about. I suspect that it will be easier for core Python developers rather that general Python programmers because they will be more intimately familiar with the conversion rules. I would be more comfortable with such a construct in C or C++, because I am more confident in those conversion rules. But, even though Python's are quite similar, I had to check myself before making my comment, because I knew they were similar, but I was not sure what they were. The situation in the stackoverflow comment is also not quite the same: asking a question about the relationship of numbers (is x modded by 2 equal to zero) is a special case of using integers in a boolean context. Saying it's Pythonic to use an integer in a boolean context does not necessarily mean it's best to always do so.
- eriknstr 9y ago> incidentally depending on non-zero numbers to become True, and zero to become False I don't feel that there is anything incidental about that. Integer zero is logically false and any other integer is logically true.