6 ms·

List Comprehension is just syntax for functional coding (filter, map) but a very good one!

von_lohengramm 4y ago
I may be the outlier here, but I have a very hard time comprehending list comprehensions. They've always seemed like a SQL query compressed into a single line (or two if you're lucky!): readable when it's simple, Lovecraftian when it's not. I've always found the functional pipeline style much more readable and much easier to explain to others, especially with IDE type hints.
- int_19h 4y ago
  SQL queries are sequence comprehensions! Python comprehensions in particular are unfortunate because the flow of the query, like in SQL, is not linear - the projection part is written first, but happens last. Thus, reading a non-trivial query requires moving back and forth to resolve the references. Compare that to C# LINQ, which is also a kind of sequence comprehension. That one not only has linear syntax where the data flow in the query is strictly left to right, but it's explicitly defined by mapping it to functional pipeline style. Thus, it ends up being a strict improvement on the latter. (Another example of "good" sequence comprehensions in this sense is XQuery FLWOR)
- maxbond 4y ago
  IMHO the key to legible comprehensions is to use them only to express composition and to put the logic into verbosely named functions. Chained pipelines (`foo.filter(...).map(...)`) are fine to me, certainly more verbose then comprehensions for better & worse, but I get lost in pipelines expressed as nested functions (`map(filter(a, ...), ...)`).
- dragonwriter 4y ago
  > they’ve always seemed like a SQL query compressed into a single line (or two if you’re lucky!): If its more than a very simple expression, with one simple for, and no if or very simple if, I try to use at least (more, with parens, if necessary): one line for the result expression, one line for each for clause, and one line for each if clause. But, while the boundary is subjective, it doesn’t take much before functional pipeline style is clearer (Python lambdas being more limited and syntacticaly cumbersome, functional pipeline style isn’t as clean in Python as it is in other languages, though.)
- snowpid 4y ago
  it depends on your problem but in many cases simple is enough imho. There are map and filter in python avalaible. I just didnt need to use them.
ogogmad 4y ago
Being pedantic: This isn't true in Haskell, because list comprehensions can use pattern matching, while map+filter can't. heads :: [[a]] -> [a] heads xs = [y | (y:ys) <- xs] -- heads [[1],[],[2,3]] == [1,2] Doing the above using maps and filters looks very different: heads' = map head . filter (not . null) Python doesn't really support Haskell-like pattern matching, so the above doesn't apply.
- pdonis 4y ago
  > Python doesn't really support Haskell-like pattern matching It does as of 3.10: https://peps.python.org/pep-0622/ https://peps.python.org/pep-0622/ Not as sophisticated as what Haskell can do, I'm sure, but I think it's a good addition to Python.
- _v7gu 4y ago
  The thing you're looking for is easily found with a Hoogle search for type (a -> Maybe b) -> [a] -> [b] Which yields mapMaybe: https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-Maybe.html#v:mapMaybe https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-.... so you end up with heads = mapMaybe safeHead
  - ogogmad 4y ago
    That doesn't look like a direct substitute that covers every case.
pharmakom 4y ago
Sorry, but Python list comprehensions are not very good compared to other languages.
- snowpid 4y ago
  why?
  - pharmakom 4y ago
    In F# list comprehensions, for example, you can have full blown expressions such as loops and conditionals. This is really nice for templating. [ if List.isEmpty items then p “No items” else ul [ for item in items do li [ item ] ] ]
    - snowpid 4y ago
      so? if len(items) == 0: return [p("no items")] else: ul( [ li(item) for item in items ] ) I am also not a fan of convoluted list comprehension (in python) so powerful is not necessarly a good thing.
      - pharmakom 4y ago
        That only works in a single purpose function. And consider this example: [ h1 “items” if List.isEmpty items then p “No items” else ul [ for item in items do li [ item ] ] ]
        snowpid 4y ago
        h1(items) + rest of my code... I might see what are you using for but I am not sure if concenating implicitly (or with line breaks / spaces) is a good design decision for a language.

I may be the outlier here, but I have a very hard time comprehending list comprehensions. They've always seemed like a SQL query compressed into a single line (or two if you're lucky!): readable when it's simple, Lovecraftian when it's not. I've always found the functional pipeline style much more readable and much easier to explain to others, especially with IDE type hints.

int_19h 4y ago
SQL queries are sequence comprehensions! Python comprehensions in particular are unfortunate because the flow of the query, like in SQL, is not linear - the projection part is written first, but happens last. Thus, reading a non-trivial query requires moving back and forth to resolve the references. Compare that to C# LINQ, which is also a kind of sequence comprehension. That one not only has linear syntax where the data flow in the query is strictly left to right, but it's explicitly defined by mapping it to functional pipeline style. Thus, it ends up being a strict improvement on the latter. (Another example of "good" sequence comprehensions in this sense is XQuery FLWOR)
maxbond 4y ago
IMHO the key to legible comprehensions is to use them only to express composition and to put the logic into verbosely named functions. Chained pipelines (`foo.filter(...).map(...)`) are fine to me, certainly more verbose then comprehensions for better & worse, but I get lost in pipelines expressed as nested functions (`map(filter(a, ...), ...)`).
dragonwriter 4y ago
> they’ve always seemed like a SQL query compressed into a single line (or two if you’re lucky!): If its more than a very simple expression, with one simple for, and no if or very simple if, I try to use at least (more, with parens, if necessary): one line for the result expression, one line for each for clause, and one line for each if clause. But, while the boundary is subjective, it doesn’t take much before functional pipeline style is clearer (Python lambdas being more limited and syntacticaly cumbersome, functional pipeline style isn’t as clean in Python as it is in other languages, though.)
snowpid 4y ago
it depends on your problem but in many cases simple is enough imho. There are map and filter in python avalaible. I just didnt need to use them.

ogogmad 4y ago

Being pedantic: This isn't true in Haskell, because list comprehensions can use pattern matching, while map+filter can't. heads :: [[a]] -> [a] heads xs = [y | (y:ys) <- xs] -- heads [[1],[],[2,3]] == [1,2] Doing the above using maps and filters looks very different: heads' = map head . filter (not . null) Python doesn't really support Haskell-like pattern matching, so the above doesn't apply.

pdonis 4y ago
> Python doesn't really support Haskell-like pattern matching It does as of 3.10: https://peps.python.org/pep-0622/ https://peps.python.org/pep-0622/ Not as sophisticated as what Haskell can do, I'm sure, but I think it's a good addition to Python.
_v7gu 4y ago
The thing you're looking for is easily found with a Hoogle search for type (a -> Maybe b) -> [a] -> [b] Which yields mapMaybe: https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-Maybe.html#v:mapMaybe https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-.... so you end up with heads = mapMaybe safeHead
- ogogmad 4y ago
  That doesn't look like a direct substitute that covers every case.

pharmakom 4y ago

Sorry, but Python list comprehensions are not very good compared to other languages.

snowpid 4y ago
why?
- pharmakom 4y ago
  In F# list comprehensions, for example, you can have full blown expressions such as loops and conditionals. This is really nice for templating. [ if List.isEmpty items then p “No items” else ul [ for item in items do li [ item ] ] ]
  - snowpid 4y ago
    so? if len(items) == 0: return [p("no items")] else: ul( [ li(item) for item in items ] ) I am also not a fan of convoluted list comprehension (in python) so powerful is not necessarly a good thing.
    - pharmakom 4y ago
      That only works in a single purpose function. And consider this example: [ h1 “items” if List.isEmpty items then p “No items” else ul [ for item in items do li [ item ] ] ]
      - snowpid 4y ago
        h1(items) + rest of my code... I might see what are you using for but I am not sure if concenating implicitly (or with line breaks / spaces) is a good design decision for a language.