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.