5 ms·

The real issue is that python doesn’t really make it easy to define anonymous functions. If you want one with more than one line, you need to name it and move i

• diarrhea 5y ago
  I always thought of that as a feature.
  • mrweasel 5y ago
    Excessive usage of anonymous functions is a major pain. JavaScript developers for some reason almost refuse to name their functions, even though it would make reading and reusing code much easier. You can make lambdas in Python, but naming function is in my mind very much a "feature".
    • tobr 5y ago
      Hm, why is it more important to name a function than, say, an if statement?
      • pjmlp 5y ago
        Code readability, specially if it spans multiple lines and has conditional code into it. Same applies to then and else branches. In a code review I don't what to read a thesis inside of a conditional branch.
      • mrweasel 5y ago
        If you just have a short one or two lines of code in a callback, maybe it's not so important. Where I have an issue is when you have five nested anonymous functions. Why wouldn't you break those out into named functions? Assuming you have five levels nested if, ignoring the fact that you might be doing something wrong, then you should name those, but that requires you to extract those code paths and put them into separate functions.
      • roenxi 5y ago
        Because an if statement is very constrained in what it can do. Every if statement has two branches (maybe one is a no-op) and one of them executes. If someone sees an if statement, it is implementing a fork in the code path. A function can do literally anything. Seeing a function call, it hasn't narrowed down the realm of what might be happening even a little bit. "lambda f:" gives away very little information about what is about to happen. "if f:" gives away some information about what is about to happen. Not a perfect rule of thumb, convoluted if statements do exist. But that is why functions are more in need of hints and comments than other control structures.
        • chriswarbo 5y ago
          > "lambda f:" gives away very little information about what is about to happen. "if f:" gives away some information about what is about to happen. I think that's an unfair comparison: If 'the thing that happens' for "if f:" is 'branch on the truthyness of f', then I agree that's pretty clear. However, if we're going to ignore the content of the branches then we should also ignore the body of the function, so "lambda f:" is also pretty clear: 'parameterise with f'. If we're worried that "lambda f:" could do pretty much anything in the body, then we should also worry that "if f:" can do pretty much anything in the branches.
          • roenxi 5y ago
            > If we're worried that "lambda f:" could do pretty much anything in the body, then we should also worry that "if f:" can do pretty much anything in the branches. That is the part common to both. If you take that common part out, you will be left with more information in the if statement than the function call. In the function, you know what arguments it (might) be interested in. You know they are evaluated. But in the if statement, you know what values it is interested in, usually get the same amoutn of information about whether they are evaluated, much clearer guarentees about how they are used and that the aspect of them that matters is their truthiness. Also the code might be about to branch. Put it this way - if(...) is a specific - and common - named function. It is a very easy argument to make that it is carrying more information about what is going on than a general anonymous function.
      • mypalmike 5y ago
        A pure function (which a lambda typically is) answers a question. It's helpful to have words describing what question it answers. The next person to read the code will actually be able to read the words. An if statement is a lower level mechanism for directing the code path within a function. If it needs a name, wrap it in a function. I often do.
        • HelloNurse 5y ago
          Control statements rarely "need" a name, but if they are significant enough to be named they can be named by extracting meaningful and somewhat reusable functions.
      • tacostakohashi 5y ago
        An if statement has a name, it's "if". It also has a condition and a body to execute conditionally. if (condition) body is just a goofy way of writing if(condition, body)
    • pjmlp 5y ago
      Fully agree, if you want to see that taken to the extreme, read Android code where people apparently only know about anonymous Java classes. Many Swing coders can also apply. It is so hard to actually pack the functionality into a separate piece of code. "Yeah, but then I have to look elsewhere" Really? What about when a method is full of stuff like that? Its readability is lost beyond hope.
    • runald 5y ago
      Have you actually used other languages like clojure, haskell, kotlin, go or ruby? Python is the weird one here for not allowing multi-line lambdas. There are legitimate and actual useful cases for multi-line lambdas, disallowing them does more harm than good. If the idea of multi-line alone compromises readability, then why even have multi-line blocks at all? Function, loop and conditional blocks should all at most have one line each. I hope you can see the absurdity of this.
      • chishaku 5y ago
        Being weird isn’t sufficient evidence for being worse which is what you seem to be arguing. Why is having to name a function doing more harm than good? Your second paragraph is a straw man.
        • runald 5y ago
          Weird as in it goes against well-established practices. If there are good, compelling reasons to disallow multi-line lambdas, other languages would have adopted it. But no, the opposite is happening, newer and recent languages actually have multi-line lambdas. Get this, even java adopted multi-line lambdas. Crazy right? What's wrong with everyone? There's nothing wrong with having to name a function. But there is something wrong with not having a choice and being forced to name a multi-line function. Just as you don't want to name every sub-expressions, you don't want to name every blocks of code. Unnecessarily naming things pollutes the namespace. Where's the strawman? The premise was that functions that spans more than a line should be given a name because they are "unreadable". I have showed that, by this logic, anything that spans more than a line is "unreadable". You can't make special exceptions and say this only applies to lambdas. Lambdas (aka higher-order functions) are blocks of code just as much as anything else.
  • ehsankia 5y ago
    Indeed, there are many such explicit omissions in python (switch statements, assignment expressions (before 3.8), increment/decrement operator, etc) that may seem to some as a bug, but it really is an explicit decision and part of what makes Python the clean and readable language it is.
• geekone 5y ago
  do python lambda expressions not qualify? https://docs.python.org/3/tutorial/controlflow.html#lambda-expressions https://docs.python.org/3/tutorial/controlflow.html#lambda-e...
  • ByteJockey 5y ago
    Lambda expressions in python are limited to a single expression. The poster explicitly calls out wanting more than one line.
    • mistaken 5y ago
      It's possible to execute statements in a lambda through exec. But it's more of hack than what it worth. print((lambda x: [exec('x = x + 1; result = x'), eval('result')][1])(1))
    • vorticalbox 5y ago
      I don't understand why you wouldn't just define a function if you needed multi lines.
      • Chris_Newton 5y ago
        I don't understand why you wouldn't just define a function if you needed multi lines. For the same reason that you wouldn’t necessarily define a function every time you wanted more than one line in the body of an if statement or for loop. In a functional programming style, typically most of your control structures are represented as higher-order functions and you pass them other functions where you might use nested blocks of statements in an imperative style. That is, where imperative pseudocode might look like this: for n in [0..10]: output_array[n] = n * n some corresponding functional pseudocode might look more like this: output_array = for_each [0..10] (n -> n * n) In some functional languages, it’s even idiomatic to write the supporting function so it reads more like this (borrowing Haskell’s $ notation, which avoids the awkward parentheses): output_array = for_each [0..10] $ \n -> n * n Now you might want a multiline body for the supporting function in much the same situations that you might want a multiline body for the imperative for loop: for n in [0..10]: location = get_location(n) route = fastest_route_to(location) times[n] = average_journey_time(route) times = for_each [0..10] $ \n -> location = get_location(n) route = fastest_route_to(location) average_journey_time(route) Similarly, if the logic you’re using in the inner part of the code is a self-contained concept, you might want to factor it out into a named function of its own in either case. This functional style can be tidy and very flexible in languages that are designed to support it. However, I wouldn’t necessarily encourage it in a language like Python, precisely because Python’s syntax and language features don’t make it natural and concise to write like this.
• mukesh610 5y ago
  IMO multi-line lambdas are unnecessary; they can't be easily documented or better maintained than a named function. If your anonymous function needs more than a statement it makes perfect sense to define it as a separate named function. Faster to find, document and maintain.
  • SketchySeaBeast 5y ago
    Do you have the same thoughts regarding JavaScript?
• hutrdvnj 5y ago
  > move its definition outside the point You can define a named function inside a named function and thus limiting its scope. def outer_func(): def inner_func(): print("hi") inner_func()
  • ehsankia 5y ago
    I honestly prefer that, anything function longer than a line probably could use a name that gives it some context, even maybe a short docstring, to make the code more readable.
• chriswarbo 5y ago
  It's not so much "lines" that are a problem; it's that lambdas cannot contain any statements. For example, here's a multi-line lambda, containing only expressions: >>> lambda f, pred, xs: [ ... f(x) for ys in xs ... for x in ys ... if pred(x) ... ] <function <lambda> at 0x1113e80d0> Here's a one-line lambda, attempting to use a statement: >>> lambda x: (x += 1) File "<stdin>", line 1 lambda x: (x += 1) ^ SyntaxError: invalid syntax Note that the parentheses are to avoid parsing a '+=' expression with 'lambda x: x' on the left and '1' on the right: >>> lambda x: x += 1 File "<stdin>", line 1 SyntaxError: cannot assign to lambda This restriction is problematic because of the following combination: - Python statements don't compose as well as expressions; we can write one statement followed by another, and we can nest statements (or blocks) inside control statements (if, else, with, etc.), but that's about it. We can't assign statements to variables, we can't call a function on a statement, or return a statement from a function, etc. i.e. we can't abstract over statements (unless we try wrapping them in a named function and using that as an expression, but that can break the underlying functionality of the statement, e.g. 'def ifThenElse(cond, true, false):' will evaluate both branches when called). - Python uses statements for a whole bunch of stuff. In particular it has a 'with foo as bar: baz' statement, rather than e.g. a 'with(foo, lambda bar: baz)' expression; the recent pattern matching functionality is a statement rather than an expresssion; defining a named function is a statement; etc. Taken together, we can often find ourselves needing to introduce a statement somewhere in our code; that requires us to turn a 'lambda' into a 'def'; but 'def' is a statement, so we have to turn any enclosing expression into a statement too; and this propagates up to disintegrate whatever expression we had; leaving us with a big pile of statements, full of boilerplate for managing scopes and names.