Hacker News Reader

Comment by Waterluvian | Hacker News Reader

I have a rule for comprehensions that I try not to break: they should only have two phrases in them. Whether that’s two “for x in y” or one “for” and one “if”. Anything more becomes confusing and illegible.

Complicated comprehensions are not clever or impressive, they’re annoying.

View on HN

You can abuse it, but the lineage of comprehensions (Haskell's list monad, SQL) make it clear that longer examples are certainly useful.

Haskell list comprehensions limited to two clauses, SQL queries limited to a single FROM and a WHERE, or a FROM and a JOIN sound pretty limited. I use Python comprehensions to do those same kinds of data querying without leaving the Python context, so seems weird to limit myself for the same reason.

Using imperative constructs certainly isn't wrong, but they tend to crawl off the right hand side of the page.

Yeah, I personally find a triply-nested comprehension to be more readable than a triply-nested loop. Once you get comfortable with the syntax, it's nice to be able to fit it compactly on your screen, so that your eyes can roll all over it without having to scroll. I agree with the general principle that terseness can be a detriment to readability, but sometimes it's nice for everything to be in one place.

I suppose this is only true in combination with verbose function names that capture the logic of the operation you're performing, with the comprehension expressing how this logic is composed. In my mind, comprehensions are sugar over map(), filter(), etc., and before I was using comprehensions I had a mess of nested calls to these functions with lots of lambdas. Comprehensions are a big step up from that as far as readability goes.

Tbh I often find I would like to use variables in sql. Something like

  americans := SELECT username FROM users WHERE country = "us";
  SELECT url, visits FROM posts, americans ON posts.author = americans.username ORDER BY visits DESC LIMIT 10;

Common Table Extensions are often good enough:

With americans as (select ...) select from ..., americans ...

https://www.draxlr.com/blogs/common-table-expressions-and-it...

Oh huh, I didn't know that was a thing. Exactly what I wanted.

The lack of variables is a major pain point for many devs when learning SQL. CTEs address one aspect. It's maybe not 1:1 or ideal, but lateral joins are a great way to get in-query variables and are extremely powerful for controlling cardinality!

https://sqlfordevs.com/for-each-loop-lateral-join

It wouldn’t work as a variable, you’d get race conditions unless you explicitly wrapped both query statements in a transaction.

It could work as an expression which gets injected into the 2nd query. So the second query would effectively have a nested SELECT statement as defined by the americans expression.

But this has the downside that if you reuse americans you have to know that it will be recomputed at each query. So unless you know the semantics of these variable-expression things over time you get race conditions. The solution again would be to wrap everything in a transaction, but at that point you just have to constantly think about transactions, which you don’t if your query is a one-liner.

Also good luck writing a query planner that has to efficiently take into account variables.

For cases like these, I use sql views - CREATE VIEW view as SELECT * .. Then DROP VIEW view.

My rule has always been that if it doesn't fit on one line it gets re-written, or if practical, I will factor out what I can into helpers. As soon as a comprehension spills over into a new line, the readability tanks for me.

With proper indention, a comp with long variable names or 2 part if is very readable for me when if is on it's own line. Put from on it's own line and it is like a sql statement.

Yeah i did a multi level nested one once including else clauses, and it didnt actually assign to anything, only side effects. Felt clever at the time.

But it was completely incomprehensible and unmaintainable. So got replaced by me later.

omg. A comprehension for side effects only. That’s so horrible I wish I could see it. :)

I worked with a guy that did this.

Instead of writing for loops he would write comprehensions everywhere because "list comprehensions are pythonic".

Think like:

  [send_welcome_email(u) for u in users]

Just hanging out in the middle of the module or function.

I prefer

sent = [(u, send_welcome_email(u)) for u in users]

Just make the function return the argument passed into it. ;)

I prefer

not_sent = users - {u for u in users if send_welcome_email(u)}

woah

I do it all the time :-)

Just make sure it isn't consuming a lot of RAM and it's totally OK.

Yes, the equivalent itertools expression is much more easily readable

Yes!! itertools. Always be aware of itertools.

What do you mean by the equivalent itertools expression? It's not clear to me how an expression like this is made more readable by itertools. I'm not sure how itertools is even relevant.

    sum(
        a + b
        for a in range(10)
        if a % 2 == 0
        for b in range(10)
    )

I don't even understand what this code does but I was referring to itertools.chain for the nested comprehension in the post

Reply on news.ycombinator.com