Most active commenters

    ←back to thread

    317 points est | 12 comments | | HN request time: 1.025s | source | bottom
    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 #
    1. 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 #
    2. joeframbach ◴[] No.17451517[source]
    [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.

    replies(2): >>17453332 #>>17453415 #
    3. 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 #
    4. stared ◴[] No.17452550[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 #
    5. carapace ◴[] No.17453215{3}[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.
    6. williamdclt ◴[] No.17453332[source]
    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)
    replies(1): >>17453797 #
    7. hellofunk ◴[] No.17453415[source]
    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.
    replies(3): >>17453649 #>>17453724 #>>17453839 #
    8. vthriller ◴[] No.17453649{3}[source]
    It's not Python, the second is actually a counterexample in JavaScript, where `node =>` is similar to Python's `lambda node:`
    9. ◴[] No.17453724{3}[source]
    10. lukeschlather ◴[] No.17453797{3}[source]
    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.
    11. ◴[] No.17453839{3}[source]
    12. aleaxit ◴[] No.17478675[source]
    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?