←back to thread

317 points est | 1 comments | | HN request time: 0s | source
Show context
passive ◴[] No.17450989[source]
This is nice.

I very frequently use something like the following:

    [node.find(SOME_XPATH).get("value") for node in tree if node.find(SOME_XPATH) is not None]
Which I can soon rewrite as:

    [found_node.get("value") for node in tree if (found_node := node.find(SOME_XPATH)) is not None]
There's a certain amount of complexity introduced, but I think removing the duplication makes up for it. This is one of the few remaining cases in Python where I feel like there's not a simple way to avoid repeating myself.
replies(3): >>17451275 #>>17452781 #>>17456957 #
stared ◴[] No.17451275[source]
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.

replies(2): >>17451517 #>>17451929 #
carapace ◴[] No.17451929[source]
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)))
replies(2): >>17452550 #>>17478675 #
stared ◴[] No.17452550{3}[source]
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.

replies(1): >>17453215 #
1. carapace ◴[] No.17453215{4}[source]
> 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.