Hacker News Reader

Comment by stared | Hacker News Reader

Still fail to see why instead of that there isn't more functional list comprehension, with maps and filters. That way we wouldn't get such problems in the first place.

For more advanced list compherensions, even JavaScript (ES6+) is more readable.

View on HN

[found_node.get("value") for node in tree if (found_node := node.find(SOME_XPATH)) is not None]

tree.map(node => node.find(SOME_XPATH)).filter(Boolean).map(node => node.get("value"))

I can deal with either language at this level of complexity. Anything more complicated needs more LoC in either language.

I vastly prefer the second one, as I would expect to see it written something like this:

  tree
    .map(node => node.find(SOME_XPATH))
    .filter(Boolean)
    .map(node => node.get("value"))

I don't use Python on a daily basis, but I find that infinitely more readable than the comprehension version (plus, it's a syntax used in several major languages)

In fairness, the Python also should be broken up. It should be:

    [
      found_node.get("value") 
      for node in tree 
      if (found_node := node.find(SOME_XPATH)) is not None
    ]

I think I also prefer Ruby/Javascript style comprehensions, but it's worth comparing well formatted code.

What is "node => ", is that valid Python? I'm new to the language and have never seen the => syntax before. The docs for 'map' don't show it either.

It's not Python, the second is actually a counterexample in JavaScript, where `node =>` is similar to Python's `lambda node:`

How about:

    [n.get("value") for n in filter(None, (node.find(SOME_XPATH) for node in tree))]

Or just:

    F0 = lambda node: node.find(SOME_XPATH)
    F1 = lambda node: node.get("value")
    result = map(F1, filter(None, map(F0, tree)))

Posible, but super ugly and unreadable. (Compare and contrast it with JavaScript; someone posted it.)

map & filter work great when one can chain methods (no matter if via methods or %>% pipes like in R) and with decent lambda functions.

If a thing is uglier than in both JS and R... well, it is not a good sign.

> Posible, but super ugly and unreadable.

That's your aesthetic opinion. Mine happens to be the opposite: I find that code (the second Python snippet) to be elegant and readable.

> (Compare and contrast it with JavaScript; someone posted it.)

    let result = tree.map(node => node.find(SOME_XPATH)).filter(Boolean).map(node => node.get("value"));

    F0 = lambda node: node.find(SOME_XPATH)
    F1 = lambda node: node.get("value")
    result = map(F1, filter(None, map(F0, tree)))

Yeah, the lambdas look like lambdas; the pattern is map.filter.map; all thoughts are tidy; F1 and F2 are generic in the node type and reusable, they look like the start of a simple combinator library for nodes. All in all, I like the Python code.

Even if you do this:

    let F0 = node => node.find(SOME_XPATH);
    let F1 = node => node.get("value");
    result = tree.map(F1).filter(Boolean).map(F2);

(Is it "let" or "var" these days?) I would say that, although the syntax seems cooler, the Python code is more conceptually elegant because map() and filter() aren't methods of a tree class.

But the real gem would be Joy code:

    F == [SOME_XPATH find] map [bool] filter ["value" get] map

Joy is the best language. A Joy compiler would be able to "open up" map and filter and write a version of F that did all the work in a single iteration. I'm actually going to be switching from Python 2 to Joy rather than Python 3, FWIW.

As an aside, this usage of `lambda` is redundant with a normal `def` statement:

    def F0(node): return node.find(SOME_XPATH)

etc. If you're binding the new function to a name anyway, why bother with `lambda` when `def` works just fine?

Reply on news.ycombinator.com