Replace reduce with listcomprehension?

Discussion in 'Python' started by ssecorp, Aug 25, 2008.

  1. ssecorp

    ssecorp Guest

    GvR wants to eliminate all the functional stuff (lambda map reduce
    filter) which kind of makes sense for Python, listcomprehensions are
    more efficient(at least as implemented inpython) from what i have
    gathered and they can express everything map/reduce/filter with
    crippled lambdas can.

    but what about this:
    reduce(lambda x,y:x*y+x,[1,2,3,4,5,6])

    how would I express that in a listcomprehension?
    ssecorp, Aug 25, 2008
    #1
    1. Advertising

  2. Actually, GvR announced that "lambda, filter and map will stay (the
    latter two with small changes, returning iterators instead of lists).
    Only reduce will be removed from the 3.0 standard library. You can
    import it from functools."

    Check the full article here: http://www.artima.com/weblogs/viewpost.jsp?thread=98196

    Luis


    On Aug 25, 7:08 pm, ssecorp <> wrote:
    > GvR wants to eliminate all the functional stuff (lambda map reduce
    > filter) which kind of makes sense for Python, listcomprehensions are
    > more efficient(at least as implemented inpython) from what i have
    > gathered and they can express everything map/reduce/filter with
    > crippled lambdas can.
    >
    > but what about this:
    > reduce(lambda x,y:x*y+x,[1,2,3,4,5,6])
    >
    > how would I express that in a listcomprehension?
    Luis M. González, Aug 25, 2008
    #2
    1. Advertising

  3. ssecorp schrieb:
    > GvR wants to eliminate all the functional stuff (lambda map reduce
    > filter) which kind of makes sense for Python, listcomprehensions are
    > more efficient(at least as implemented inpython) from what i have
    > gathered and they can express everything map/reduce/filter with
    > crippled lambdas can.
    >
    > but what about this:
    > reduce(lambda x,y:x*y+x,[1,2,3,4,5,6])
    >
    > how would I express that in a listcomprehension?


    You can't. And AFAIK your are wrong - GvR doesn't wan to eliminate the
    functional stuff.

    http://www.artima.com/weblogs/viewpost.jsp?thread=98196
    http://www.python.org/dev/peps/pep-3099/



    Diez
    Diez B. Roggisch, Aug 25, 2008
    #3
  4. Correction:
    I guess the link I provided above is old news...
    In the more recent Python 3000 FAQ, GvR says:

    Q. If you're killing reduce(), why are you keeping map() and filter()?

    A. I'm not killing reduce() because I hate functional programming; I'm
    killing it because almost all code using reduce() is less readable
    than the same thing written out using a for loop and an accumulator
    variable. On the other hand, map() and filter() are often useful and
    when used with a pre-existing function (e.g. a built-in) they are
    clearer than a list comprehension or generator expression. (Don't use
    these with a lambda though; then a list comprehension is clearer and
    faster.)

    So it seems only reduce will be eliminated.

    Luis
    Luis M. González, Aug 25, 2008
    #4
  5. Luis M. González schrieb:
    > Correction:
    > I guess the link I provided above is old news...
    > In the more recent Python 3000 FAQ, GvR says:
    >
    > Q. If you're killing reduce(), why are you keeping map() and filter()?
    >
    > A. I'm not killing reduce() because I hate functional programming; I'm
    > killing it because almost all code using reduce() is less readable
    > than the same thing written out using a for loop and an accumulator
    > variable. On the other hand, map() and filter() are often useful and
    > when used with a pre-existing function (e.g. a built-in) they are
    > clearer than a list comprehension or generator expression. (Don't use
    > these with a lambda though; then a list comprehension is clearer and
    > faster.)
    >
    > So it seems only reduce will be eliminated.


    Nope. From the link you provided yourself:

    """
    Only reduce will be removed from the 3.0 standard library. You can
    import it from functools.
    """

    Diez
    Diez B. Roggisch, Aug 25, 2008
    #5
  6. ssecorp

    Guest

    Luis M. González, citing Guido:
    > A. I'm not killing reduce() because I hate functional programming; I'm
    > killing it because almost all code using reduce() is less readable
    > than the same thing written out using a for loop and an accumulator
    > variable.


    (So reduce is now in itertools). Try to pry folds from the hands of
    haskell programmers :)
    I think they think that folds are more clear than explicit loops...

    Bye,
    bearophile
    , Aug 25, 2008
    #6
  7. On Tue, 26 Aug 2008 00:53:35 +0200, Diez B. Roggisch wrote:

    >> So it seems only reduce will be eliminated.

    >
    > Nope. From the link you provided yourself:
    >
    > """
    > Only reduce will be removed from the 3.0 standard library. You can
    > import it from functools.
    > """


    functools isn't in the standard library???

    *wink*

    Seriously, I think Guido meant "built-ins". Since I don't agree with him
    that reduce() is hard to read, I disagree that accumulators are easier to
    use. But since reduce is only an import away, I'm satisfied.


    --
    Steven
    Steven D'Aprano, Aug 26, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brian Blais
    Replies:
    1
    Views:
    365
    Bruno Desthuilliers
    Jun 27, 2006
  2. Greg Ewing
    Replies:
    2
    Views:
    332
    Dieter Maurer
    Jun 29, 2006
  3. Alun
    Replies:
    3
    Views:
    4,480
    Masudur
    Feb 18, 2008
  4. cirfu
    Replies:
    7
    Views:
    226
    Maric Michaud
    Jun 23, 2008
  5. Prasad S
    Replies:
    2
    Views:
    215
    Dr John Stockton
    Aug 27, 2004
Loading...

Share This Page