[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)))

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?

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.