Hacker News Reader

Comment by whalesalad | Hacker News Reader

You had me nodding in agreement until the last paragraph. Functions are first class in Python. You can pass them all over the place and use them the same way you would in JS. You don’t have Lodash but frankly it’s not needed. The stdlib, functools and itertools are pretty much all you could ever ask for.

View on HN

I think I meant the treatment of anonymous functions - lambdas are limited compared to normal functions.

If you need more power than a lambda you would use a nested function, e.g.

    def a(n):
      def b():
        print(n)
      return b

That's a lot of boilerplate for a closure…

    def a(n):
        return lambda: print(n)

That's a couple characters over most languages I normally use. Plus lambdas have a number of strange warts and restrictions (no multi-line lambdas?) that leave me feeling that Python really dislikes traditional functional programming constructs.

Python has become less functional over time. It’s also not a particularly good OO language either. It’s really a more descriptive sort of bash that became ubiquitous despite its short comings.

The trivial lambda case is short, and you can do what the parent said if you want to do something that doesn't fit into the trivial lambda case well.

The "lambda" keyword isn't :(

Where's the boilerplate? "def b():" and "() => {}" are both 8 characters.

It is annoying that you have to give the function a name, though.

On the one hand it’s annoying, on the other it enforces a discipline of thought in the same way that having to name variables does.

That’s an interesting principle, something like “a block of code that is complex enough to be written across multiple lines of code ought to be given a name,” but standard idiomatic Python already violates that principle by featuring multiple lines in the body of a for loop. The fact that the body of a for loop can be multiple lines but the “body” of a lambda cannot is an arbitrary syntax inconsistency.

    def b(x):
      return x + 1

    x => x + 1

Nesting functions like this can have a bad performance impact because functions in Python are objects. Normally, all of those function objects are instantiated once when you load the module. However nested functions will be instantiated at runtime every time their parent is called, even if they aren’t used. This cost is perceptible in hot paths.

Are lambdas different?

I’ve never seen it create a bottle neck, have you?

It will definitely be a problem if you use JIT interpreter like pypy

A lambda also behaves this way; it’s how it captures the closure scope.

The lack of multi-line lamdas is one of my biggest gripes with python.

If you feel the need to use a multi line lambda you should be using a regular function.

This is a code smell for sure.

Regular functions definitions can't be used as expressions.

You are basically saying that one should never need a multi-line lambda. Obviously, I disagree.

If you need to express something complex enough that you can't do it in a single statement in Python, it deserves to have a name (or more likely, it already has one in the standard library).

But python for loops can and typical do have multiple lines, yet that “block” inside the for loop doesn’t have a name. The fact that the body of a for loop can have multiple lines but an anonymous function cannot is a purely arbitrary syntax limitation, and the principle you stated ought to apply (or not apply) equally to both use cases.

Thanks for writing this, that clarifies the issue more clearly and concisely than what I had in mind.

I will mention a core aspect of my argument, to add to your point.

When you make a named function and then use it separately somewhere else, there is a loss of locality. The logic is now further from its point of use. This is a cost, and sometimes it is an unreasonable one.

i'd agree with this, except you can have a function within a function in Python to limit scope and keep it local. yeah, you have to define it before the code using it - sometimes this feels like a boon though, especially compared to huge inline lambdas. so over time, my annoyance with this has decreased, and it doesn't bother me anymore.

This doesn't follow: for loops are there specifically for cases of the complexity that can't be handled by other constructs (like comprehensions). Anonymous functions are not, for the complex cases you give the construct a name.

It's a very intentional language limitation, much as semantic whitespace is an intentional limitation.

And there is actually a language difference. A for loop is a statement. A lambda is an expression. Python doesn't let you put statements into expressions.

I tentatively disagree with both of you.

I've sometimes wondered whether code would be universally clearer if all you could do in a loop is have a one-liner or call another function/method (mainly when looking at my own code within loops and thinking WTF!!!).

Would probably cause issues when teaching programming though. It would be interesting to have a compiler switch that enforced this...

What comes to mind immediately is that you would lose the ability to `break` unless you had another convention like returning a specific value to indicate you want to break.

If you are limited to one statement you could still do something along the lines of the following (no particular language):

  foreach ( $item in $list )
  {
    if ( 1 == some_function( $item ) )
    {
      continue;
    }
    else
    if ( 2 == some_function( $item ) )
    {
      break;
    }
    else
    {
      another_function( $item );
    }
  }

But I would immediately concede that it is starting to miss the entire point of why it was enforced in the first place...

I actually like this style (or similar if not quite as extreme). I find it's much clearer what's going on.

Large anonymous functions are very much a thing in JavaScript.

This trend will gradually fade into the history books. Just because it’s a thing doesn’t mean it’s a good one.

Large anonymous functions are a thing in every modern language I can think of except python. It’s the only sensible solution in the case of functional method chaining, which is much more readable than nested comprehensions. Python just got this one wrong.

Large anonymous functions are rarely used in rust, go, python, java (streams instead), or cpp.

Streams and repeated application of short anonymous functions are a much better solution to the method chaining issue.

If js supported better streaming tools, they'd be less common in js too.

I've started to use Python type hints, but even with typing I like to label my names things that describe local concerns (types are often more general than what you mean to say), and sometimes I'll deliberately shorten the names to make a Python lambda fit where in another language with bracketing I'd just take an extra 1-2 lines and format the line differently.

I've written snippets or data structures one way or another as I'm sure many have, and in my experience the results have been mixed. This and the fact that reduce has no bearing on your app architecture, I do see this as arguing over a small and vague gain or loss.

> Regular functions definitions can't be used as expressions

I’m having a difficult time understanding what you mean here. Can you offer an example?

I have never felt compelled to write a multi line lambda.

Python can't replicate the structure of this JavaScript code:

  fooBaz(x => {
    // multiple lines of logic
  })

In python, you are forced to move the logic away from the point of usage, which means you lose some locality. This loss is sometimes not worth getting a "name" for the logic.

Of course, sometimes it is better to create a named function away from the point of usage, but I don't think that is always the case.

This is the silliest thing I see paroted. Anonymous functions are there for one offs. Sometimes a one-off is two lines. Breaking it out into a separate function is ridiculous.

You end up seeing functions declared within functions so that people can work around this limitation and it is grotesque.

Multi-line lambda is not code smell.

There are a lot of cases like GUI programming where you need a lot of handlers which are suitable for lambda because they don't have a good name, and should never be called manually, and often they have multi-lines of codes.

In fact, they're first class in Go too, in fact there's fewer languages where that's not the case than is, I'd imagine.

While functions are first class in Go, the limitations of the type system make them less ergonomic to use, I think. Without user defined generics, many of the common uses of first-class functions become a lot less convenient to use.

Do you have an example where that's the case?

map, filter, fold, etc.

One easy example is map functions.

In typescript, if I have a bunch of "User" objects where each user has an "name" and "age" field, and I want to print a comma separated list of all those names formatted as "name -- age", it's simple. I write:

    let userNamesList = let userNames = users.map(u => `${u.name} -- ${u.age}`).join(", ")
    console.log(userNamesList).

This is possible in no small part because map is generic.

In go, to get the same level of expressiveness, I'd have to write the following stuff around it:

    func mapUsersToStrings(f func(u User) string, users []User) []string {
        result := make([]string, len(users))
        for i := 0; i < len(users); i++ {
            result = append(result, f(users[i]))
        }
    }

And after writing that boilerplate, I can finally write:

    userNamesList := strings.Join(mapUsersToStrings(func(u User) string { return fmt.Sprintf("%s -- %d", u.name, u.age) }), ", ")

That boilerplate, of having to write a specialized map/filter/etc function with a for loop for every combination of types you transform between (mapUsersToStrings, mapUsersToAddresses, mapUsersToAges) is really annoying.

It's harder to point to many other cases because, simply enough, people don't write such cases. The fact of the matter is just that go libraries make very sparing use of first-class functions because the lack of generics prevents it from working well, and so we end up with an entire language ecosystem where code is harder to read and with fewer simple abstractions reused across it.

You can still write any code without good generics or first-class functions, you'll just have more programmers writing more code with less clean abstractions.

If you add in Typescript as he said, is a much better proposition than mypy.

Reply on news.ycombinator.com