Hacker News Reader

Comment by ezrast | Hacker News Reader

As a fellow member of the hates-Python-but-not-enough-to-quit-my-job-over-it club, comprehensions are just the worst. Uses variables before defining them, can't be readably broken over multiple lines, overloads multiple pieces of syntax, reads inside-to-out instead of left-to-right. Ugh.

View on HN

What is awful about:

  foo = [transform(bar) for bar in baz.list() if condition(bar)] ?

Seems very readable and expressive. Or are you complaining about how they execute?

Also \ used judiciously with proper indentation can break statements over multiple lines without too much pain.

Yea, I like list comprehensions. I mean they make sense once you're use to reading the syntax. That's just like the following in Scala:

   foo = baz.list().filter{ bar => condition(bar) }.map(transform(_)).toList

If it's your first time looking at Scala, you'd probably be like, "What the fuck is that shit?" but as you learn the language, these types of patterns become common and make a lot of sense.

I mean it's not like weird rules in natural language. At least the grammars for computer languages are strict, with very few edge cases (compared to human/spoken language).

I hope you mean:

    foo = baz.list().filter(condition).map(transform).toList

No need to create the extra anonymous functions.

Does Scala have line continuation? I got really used to pipes from R (which I guess come from F#/Elixir), which in turn got me really comfortable with multi-line statements like:

    foo = baz.\
        list().\
        filter{ bar => condition(bar) }.\
        map(transform(_)).\
        toList

IMO this is about as readable as it gets. It's like bullet points enumerating each step in the "algorithm" that produces a `foo`.

AFAIK Javascript also uses this pattern a lot.

I think that Scala uses semicolon terminated lines so you would write something like:

    foo = baz
        .list()
        .filter{ bar => condition(bar) }
        .map(transform(_))
        .toList;

Scala doesn't require the semi-colon at the very end, but it does allow for them if you really want two statements on the same line.

Edit: and yes, that line separation works fine, both compiled and in the REPL.

BTW similar syntax in javascript, ruby, c#, etc.

1: When I hit the opening bracket, I don't know whether I'm looking at an array literal or a comprehension. I have to read ahead a few tokens to disambiguate.

2: When I hit `transform(bar)`, I don't know what `bar` is either. I have to jump forward to disambiguate again.

3: Once I hit `for bar in` I realize I'm in a comprehension, but that's still not enough to figure out what `transform(bar)` is acting on. I have to read to the end of the `if` condition, then backtrack to the beginning.

bonus reason: why not `list(baz)`? Is there actually some logic to when Python uses methods and when it uses global functions? If so, please tell me.

another bonus reason: when I was learning Python, I found the keyword reuse genuinely confusing. I would try to write for loops like `for x in my_list if condition(x):` and couldn't figure out why it didn't work because I knew I had seen that syntax somewhere before.

Now, your particular example isn't that bad, but if you make it just a little more complicated you get something like this aberration:

    foo = [transform(bar) if bar.property else bar for bar in baz.list() if condition(bar)]

Nothing will convince me that you're not a mutant if you think that's clear and concise.

Meanwhile, over in Ruby-land, we write this:

    baz.each.select{ |bar|
      condition(bar)
    }.map{ |bar|
      bar.property ? transform(bar) : bar
    }

Which to me parses very easily into meat-brain logic, in small chunks, with a single pass:

-Start with `baz`

-Consider each item

-Select only those `bar`s that meet `condition`

-Map each `bar` to...

-`transform(bar)` when `property` is true; itself otherwise (okay, natural language actually more closely resembles Python-style ternaries here. Sue me).

P.S. apologies for the multiple edits; I am an HN formatting noob.

> When I hit the opening bracket, I don't know whether I'm looking at an array literal or a comprehension. I have to read ahead a few tokens to disambiguate.

All research I have seen says that proficient readers of a language read closer to a line at a time than a token at a time, so I suspect that not really a problem so much as a rationalization of aesthetic preference.

> bonus reason: why not `list(baz)`? Is there actually some logic to when Python uses methods and when it uses global functions?

list is a built-in type, and (as is usually the case for Python types) list() is the type constructor. There are other global functions in Python and there is room for debate over whether they make sense over methods, but constructors for built-types are pretty clear.

baz.list() is a method on baz. Assuming baz is iterable, list(baz) is valid, it's just different than baz.list().

I generally like python's list comprehensions, but they have some ugly warts. For example, a simple comprehension looks like this:

  foo = [transform(bar) for bar in baz.list()]

Adding an if condition looks like this:

  foo = [transform(bar) for bar in baz.list() if condition(bar)]

But an if/else expression looks like this:

  foo = [if condition(bar) transform(bar) else other_transform(bar) for bar in baz.list()]

Adding an else requires completely rewriting the line! Super ugly and inconsistent.

Edit: formatting... don't know why my the 'list()' in my last example is disappearing

maybe it's bad form but I generally prefer to break my list/dictionary/set comprehensions into various lines. For me it increases the readability

    foo = [
        if condition(bar) transform(bar) else other_transform(bar) # 1: storage
        for bar in base.list() # 2: iteration
        if bar_tester(bar). # 3: filtering
    ]

to each his own I suppose, until the PEP8 police come and get us all!!!

Filters and ternaries aren't the same kind of thing (ternary if/else are analogous to SQL SELECT-clause case statements, filter if is analogous to SQL WHERE-clause; the positions in Python conditionals, which are very much like SQL SELECT statements, follows that analogy.)

Instead of asking "what is awful about X", how about considering "what would make it better"?

I think this would be easier to read, given that what's inside the [] now looks almost exactly like the equivalent code without using a list comprehension:

    foo = [for bar in baz.list() if condition(bar) transform(bar)]

(Disclaimer: I am not a regular Python user. Maybe that ordering conflicts with a syntax for something else.)

You don't need line continuations to split comprehensions because the delimiters already allow you to split lines.

I come from a mathematics background and when I first saw comprehensions I really liked them. They read remarkably similar to Set Builder Notation [0]. I think so long as you don't go crazy they are perfectly readable. But at the end of the day the onus is still on the developer to ensure their code is readable.

[0] https://en.wikipedia.org/wiki/Set-builder_notation

Bachelor's in math myself, although my math interests and my programming interests have admittedly (and regrettably) not intersected very much in my career. I do tend to think about problems more "imperatively" in my head and then struggle sometimes to translate those concepts into declarative math notation when doing proofs; if I were able to make that leap more naturally maybe I'd benefit from the notational similarities more.

Comprehensions were inherited from the math and science community where such constructs are used a lot. It happens that Python is very popular in those communities.

And does not allow access to the list being created from within the list comprehension. Which makes a whole slew of things hard to impossible using comprehensions.

Yup. Ruby blocks, FTW.

ruby blocks are exceptionally difficult to rationalize at first (well, at least they were for me). I get that they are beautiful (because they are) but it was a major stumbling block on my way to understanding ruby.

Reply on news.ycombinator.com