Hacker News Reader

Comment by bad_user | Hacker News Reader

Only by not working with anonymous functions can anybody come up with such an impression.

Python has at least 3 features that are not needed in languages that have proper support for anonymous functions and that are more expression oriented:

1. for comprehensions

2. the with statement

3. decorators

You cannot work efficiently with higher-order functions until you have anonymous multi-line functions, period - also, Python's single-line lambdas would be a lot more useful if Python wouldn't have been so statement oriented, unfortunately in practice they are useless.

In regards to your points:

a) no, I don't buy that

b) ordering matters, we read code as we are reading text, top-down, left to right

View on HN

> Python has at least 3 features that are not needed in languages that have proper support for anonymous functions and that are more expression oriented:

> 1. for comprehensions

Off the top of my head Scala, Erlang, and Haskell -- all of which are "more expression oriented" than Python (and all of which have robust support for anonymous functions including multiline anonymous functions -- the latter despite, like Python, having indentation-sensitive syntax), all have comprehension syntaxes like Python's for comprehensions.

So, I'm not entirely buying the idea either that "being more expression oriented" or "having proper support for anonymous functions" eliminates the utility of comprehension syntax.

Well, Scala and Haskell's comprehensions are monad comprehensions, mapping to operations such as map, filter and flatMap/bind. Python's for comprehensions only work on things that are iterable, which IMHO is a severe design limitation and makes them less useful than they should be. Think at Async I/O abstractions, like futures / observables / iteratees, which are not iterables.

And yes, if Python makes it easier to work with higher-order functions and such combinators / operators become the norm, then we'll talk about 2 non-orthogonal and conflicting features.

Python is the only language I know that added for comprehensions before proper support for anonymous functions. All the other languages I worked with (including Clojure, to be on topic) had anonymous functions before the syntactic sugar built on top. Clearly Python has a problem here.

> Python is the only language I know that added for comprehensions before proper support for anonymous functions. All the other languages I worked with (including Clojure, to be on topic) had anonymous functions before the syntactic sugar built on top. Clearly Python has a problem here.

Wait, first you claimed that Python wouldn't need comprehensions if it had better anon function support, and now you've claimed that Python has a problem because it added for comprehensions before anon function support, even though languages with anon function support still find the need for for comprehensions.

You seem to be convinced that Python is wrong, but not really committed to any consistency in the reason that Python is wrong.

The 2 statements are consistent.

You can live without for comprehensions if you have good anonymous functions support. If Python adds better anonymous functions support, its for comprehensions will be conflicting and much less useful than in languages that had good anonymous functions support from the beginning.

Either way, Python will never get multi-line anonymous functions support, since it's first of all considered to be un-pythonic. So we're having this discussion for nothing - I fell out of love with Python some time ago, if you still like it than good for you.

> You can live without for comprehensions if you have good anonymous functions support.

You can live without either, as decades of C programmers have demonstrated. Both are beneficial, as theeir widespread popularity in newer language attests. Neither is a perfect substitute for the other, as the fact that they tend to be both present in many newer languages, rather than being exclusive.

> its for comprehensions will be conflicting and much less useful than in languages that had good anonymous functions support from the beginning.

I don't see the "conflict" asserted here. I've used Ruby fairly heavily -- which has, in the relevant sense, far better anonymous function support than Python (even though it has different quirks) -- and certainly as nice as Ruby blocks are, a clean comprehension syntax is pretty much the main thing I find myself wishing I had sometimes in Ruby that Python has.

And, sure, Python's comprehensions may be less general than, e.g., Scala's, but switching them to be monadic rather than iterator based doesn't require better anonymous function support, it just requires changing which protocol they depend on.

Can you please explain to me what's important about these functions being anonymous? Why, specifically, they shouldn't be given a name?

How do you define working "efficiently with higher-order functions"? Given that Python fully supports higher-order functions, I am really curious what you could mean. I didn't downvote you, but it may have to do with your pointed assertion here, without anything in the way of an argument.

As to "ordering matters"; sure, but as the functions a nontrivial program calls are inevitably described as a graph, they must necessarily be defined in some arbitrary linear order anyway.

    some_collection.where(x -> x.name == 'foo').sort_by(x -> x.age)

These functions are tiny and trivial. They don't need names, and if you were to give them names, the extra weight becomes burdensome. Not just in syntax duplication, but the redundancy of the name as a comment on the trivial function body.

    nameIsFoo = x -> x.name == 'foo'
    getAge = x -> x.age
    some_collection.where(nameIsFoo).sort_by(getAge)

Note that giving the functions names has also changed the source order of the function bodies. Now you need to do a mental cross-reference to follow, instead of being able to read the definitions inline.

Sure, but those are one-line functions, which Python supports through lambdas. (Incidentally, some of them could be done with the operator module, without defining a new function). I would argue that once you write a multi-line function, it makes sense to give it a name and define it separately, which makes the "no multi-line anonymous functions" complaint less pressing.

Let me give you an example from my experience.

I wrote an elegant parser definition library, used for parsing specialized output of ... never mind.

It had hierarchic specifications (regular expressions etc) of parsing states, along with anonymous functions which stored away parsed data and sent the parser among different states.

New juniors could after a few hours use this to quickly parse complex text documents.

I cursed a lot while trying to port this to Python. :-( A dozen named sub-ten lines functions specified by names and referenced inside a parser structure? Just didn't work.

Edit: The point is, there are use cases where real lambdas are useful (except from map etc). It is just weird to argue otherwise.

I'm a python guy and I totally agree that multiline anonymous functions greatly enhance the readability of code in certain applications. You can do everything with named functions, but it's not always the best method for conveying meaning.

I can live without multiline anonymous functions - but I'd make use of them if they did exist.

Imagine having to build functions with names for each while, if/else and foreach statements. Because that's what it feels like when working with async I/O in Python, a complete pain in the ass compared to other languages.

Scala sample:

      cache.get[String]("name").flatMap {
        case Some(value) => value
        case None =>
          database.query("names").head.flatMap {
            case Some(id, value) =>
              cache.set("name", value, 10.minutes)
                .map(_ => value)

            case None =>
              Future.successful("Anonymous")
          }
      }

BTW, in this sample, for comprehensions are not that useful. But if you're using Scala-Async, you can write that in a style resembling blocking I/O:

      async {
        val cached = await(cache.get[String]("name"))

        cached match {
          case Some(value) => value
          case None =>
            val fromDB = await(database.query("names").head)
            
            fromDB match {
              case Some(id, value) =>
                await(cache.set("name", value, 10.minutes))
                value

              case None =>
                "Anonymous"
            }
        }
      }

In both cases multi-line anonymous functions are leveraged.

Reply on news.ycombinator.com