Yes 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.

Bad 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
  }

I 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.

It 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?

The 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.

Furthermore I would prefer

    def even(x): return not(x % 2)

I 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?"

Though you might find core developers disagreeing with that sentiment.

https://stackoverflow.com/a/3175293/1763356

I 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.

> 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.

Incidental to properties of numbers themselves; it's a part of the language, not a part of numbers. The function is asking a question about the property of numbers. I find it more clear when the computation to determine that property depends on number properties, not language properties.

That is a good point, and it makes sense to think of it that way. However I think that it can also be a bit "dangerous" to think too much in terms of the properties of the numbers when working with software due to the fact that for example arbitrary floats cannot be precisely represented in a limited amount of bits like we have in computers. I already hold the view that the numbers we are dealing with when working on computers are an incomplete representation of the ideals of ℝ and ℂ and their likes, so to me then it is ok to reason about code in terms of properties that stem from the language in use.

not isn't a function; no need for brackets.

I use parentheses liberally so I don't have to think about precedence so much both when writing and when later reading.

That said I don't add unneeded parentheses for simple expressions or sub-expressions consisting only of exponents, multiplications, divisions, additions and/or subtractions.