4 ms·

Heh, all of these points could easily be applied to Python as well. All the concepts are there in addition to the for loop. It's nice how you can do a lot of fu

Heh, all of these points could easily be applied to Python as well. All the concepts are there in addition to the for loop. It's nice how you can do a lot of functional programming in Python with these simple tools (map, filter and reduce (Haskell's foldl). I wonder why there aren't more people advocating the use of these functions in Python programs instead of for loops.

Dn_Ab 16y ago
Java's younger cousin C# also has this with Select, Where and Aggregate. But sometimes the foreach and even the for loop actually makes more sense, in particular when dealing with very imperative algorithms or are not acting over a (full) sequence at all. I'm usually only reading and not writing python but I think list comprehensions are more idiomatic. Based on some comments I've seen here I also kind of get the impression comprhensions are abused.
- Fargren 16y ago
  Well, if you don't want to work with the whole sequence, you can filter it. But yeah, in those cases and some others, the for loop may be more idiomatic and better performing.
  - Dn_Ab 16y ago
    Yes I'm talking about being able to stop early for one example. Or if the thing you are dealing with is not actually a sequence for another.
    - darklajid 16y ago
      The former can probably be solved for lots of cases by TakeWhile(), which evaluates before consuming more elements and could be used to replace "abort the loop" patterns. The latter is a different thing.. 1: http://msdn.microsoft.com/en-us/library/bb534804.aspx http://msdn.microsoft.com/en-us/library/bb534804.aspx
      - deleted 16y ago
        [deleted]
- Stormbringer 16y ago
  "Java's younger cousin C#" We prefer the terms: "brother by a different mother" or if they're being naughty: "red headed step-child".
  - genera 16y ago
    s/naughty/stupid
T-R 16y ago
I've gotten the impression that there are, in a sense - in python, list comprehensions are usually preferred over for-loops in places where you would use map and filter, and the most common use cases for fold/reduce are covered by functions like sum and join. List Comprehensions also tend to be preferred over higher order functions, perhaps for readability, but also, in python 3, the higher order functions return generators, which don't always play nicely with mutable data. For-loops are still suitable for actions (which mutate state or for some other reason need to be evaluated in order) - you see this in Haskell, too, though, with Control.Monad's forM_ and the like.
- athom 16y ago
  After reading this, I got to wondering if I could hijack sum into joining lists. My first attempt didn't work: sum([ range(n,n+5) for n in range(5) ]) just gave me "TypeError: unsupported operand type(s) for +: 'int' and 'list'", which didn't make a lot of sense. Where did I pass an 'int' by itself? Well, according to the help, sum takes a second argument: a starting value, which defaults to 0. So, I wondered, what if I were to pass it an empty list...? sum([ range(n,n+5) for n in range(5) ], []) came back with: [0, 1, 2, 3, 4, 1, 2, 3, 4, 5, 2, 3, 4, 5, 6, 3, 4, 5, 6, 7, 4, 5, 6, 7, 8] Holy $#!7 I'd been wanting a way to join multiple lists without having to write another ugly little function! Anyone know if this particular trick is common practice?
  - tkahn6 16y ago
    That's actually quite clever.
    - athom 16y ago
      Thanks, but I got a little update: it won't work on strings. The help says as much, in fact. Actually, what it says is, "Returns the sum of a sequence of numbers (NOT strings)," which I think is meant to imply it won't parse numbers out of strings, but in theory, sum should be able to concatenate strings as easily as it does lists, with the right start argument. Instead: >>> sum([['room315'], ['room2']], []) ['room315', 'room2'] but: >>> sum(['room315', 'room2'], '') TypeError: sum() can't sum strings [use ''.join(seq) instead] Say, what??? I'm not sure, but I think sum is specifically watching for strings, and throwing a TypeError if it finds one. Otherwise, if it's simply using the + operator internally, as its list-handling behabior seems to imply, it should mash strings together just as happily! Oh, well. The join function is the right one for that job. It just seems a bit of wasted effort, to me.
pjscott 16y ago
Technically, Python's reduce function is equivalent to a duck-typed version of Haskell's foldl1' function. It's strict, and it has no starting value argument. (Nitpicking forever!)
- rwl 16y ago
  Well, as long as we're nitpicking... Python's reduce function has an optional starting value argument: http://docs.python.org/library/functions.html#reduce http://docs.python.org/library/functions.html#reduce
tel 16y ago
Guido doesn't like them at all and has been trying to get them out of Python for a long while now. http://www.artima.com/weblogs/viewpost.jsp?thread=98196 http://www.artima.com/weblogs/viewpost.jsp?thread=98196
xi 16y ago
I, for one, prefer fors and ifs to high order functions when reading and writing Python code. I use the latter very sparingly and only when it does not violate the overall "pseudocode" feel of the code. For that, generator expressions and functions like `any`, `all`, `sum` are of great help. For example, I have nothing against the code like this: if any(foo.is_cond for foo in foos): do(bar) but I cringe when I see `import functools, operator`, `reduce` or complex nested list comprehensions. It may work better in ML-derived functional languages because function definitions there, both anonymous and named, are extremely lightweight. This part of the language is highly optimized by necessity as high order functions is the only way to express iteration and other control flow constructs. But in Python, though not particularly heavyweight, function definitions don't mix well with regular code. Also I'm not sure if the author is completely fair with his loop example. Add a few local variables, `break` or `continue`, and the high order form may actually become less intuitive.
RyanMcGreal 16y ago
I rarely use for loops in Python. Most of the time I use list comprehensions, which are much more terse and expressive than loops and, at least to me, are easier to parse than map/filter/reduce functions.
- KirinDave 16y ago
  Funny, that. List comprehensions are actually sytactically and semantically more difficult than folds, modulo your logic. Honestly, I suspect the Haskell style and the curious Python cultural disdain for real lambadas have far more to do with your confort than any absolute metric of comprehension.
  - skm 16y ago
    Anyone who has disdain for real lambadas just doesn't know what they're missing: http://www.youtube.com/watch?v=5AfTl5Vg73A http://www.youtube.com/watch?v=5AfTl5Vg73A
deleted 16y ago
[deleted]

Dn_Ab 16y ago

Java's younger cousin C# also has this with Select, Where and Aggregate. But sometimes the foreach and even the for loop actually makes more sense, in particular when dealing with very imperative algorithms or are not acting over a (full) sequence at all. I'm usually only reading and not writing python but I think list comprehensions are more idiomatic. Based on some comments I've seen here I also kind of get the impression comprhensions are abused.

Fargren 16y ago
Well, if you don't want to work with the whole sequence, you can filter it. But yeah, in those cases and some others, the for loop may be more idiomatic and better performing.
- Dn_Ab 16y ago
  Yes I'm talking about being able to stop early for one example. Or if the thing you are dealing with is not actually a sequence for another.
  - darklajid 16y ago
    The former can probably be solved for lots of cases by TakeWhile(), which evaluates before consuming more elements and could be used to replace "abort the loop" patterns. The latter is a different thing.. 1: http://msdn.microsoft.com/en-us/library/bb534804.aspx http://msdn.microsoft.com/en-us/library/bb534804.aspx
    - deleted 16y ago
      [deleted]
Stormbringer 16y ago
"Java's younger cousin C#" We prefer the terms: "brother by a different mother" or if they're being naughty: "red headed step-child".
- genera 16y ago
  s/naughty/stupid

T-R 16y ago

I've gotten the impression that there are, in a sense - in python, list comprehensions are usually preferred over for-loops in places where you would use map and filter, and the most common use cases for fold/reduce are covered by functions like sum and join. List Comprehensions also tend to be preferred over higher order functions, perhaps for readability, but also, in python 3, the higher order functions return generators, which don't always play nicely with mutable data. For-loops are still suitable for actions (which mutate state or for some other reason need to be evaluated in order) - you see this in Haskell, too, though, with Control.Monad's forM_ and the like.

athom 16y ago
After reading this, I got to wondering if I could hijack sum into joining lists. My first attempt didn't work: sum([ range(n,n+5) for n in range(5) ]) just gave me "TypeError: unsupported operand type(s) for +: 'int' and 'list'", which didn't make a lot of sense. Where did I pass an 'int' by itself? Well, according to the help, sum takes a second argument: a starting value, which defaults to 0. So, I wondered, what if I were to pass it an empty list...? sum([ range(n,n+5) for n in range(5) ], []) came back with: [0, 1, 2, 3, 4, 1, 2, 3, 4, 5, 2, 3, 4, 5, 6, 3, 4, 5, 6, 7, 4, 5, 6, 7, 8] Holy $#!7 I'd been wanting a way to join multiple lists without having to write another ugly little function! Anyone know if this particular trick is common practice?
- tkahn6 16y ago
  That's actually quite clever.
  - athom 16y ago
    Thanks, but I got a little update: it won't work on strings. The help says as much, in fact. Actually, what it says is, "Returns the sum of a sequence of numbers (NOT strings)," which I think is meant to imply it won't parse numbers out of strings, but in theory, sum should be able to concatenate strings as easily as it does lists, with the right start argument. Instead: >>> sum([['room315'], ['room2']], []) ['room315', 'room2'] but: >>> sum(['room315', 'room2'], '') TypeError: sum() can't sum strings [use ''.join(seq) instead] Say, what??? I'm not sure, but I think sum is specifically watching for strings, and throwing a TypeError if it finds one. Otherwise, if it's simply using the + operator internally, as its list-handling behabior seems to imply, it should mash strings together just as happily! Oh, well. The join function is the right one for that job. It just seems a bit of wasted effort, to me.

pjscott 16y ago

Technically, Python's reduce function is equivalent to a duck-typed version of Haskell's foldl1' function. It's strict, and it has no starting value argument. (Nitpicking forever!)

rwl 16y ago
Well, as long as we're nitpicking... Python's reduce function has an optional starting value argument: http://docs.python.org/library/functions.html#reduce http://docs.python.org/library/functions.html#reduce

tel 16y ago

Guido doesn't like them at all and has been trying to get them out of Python for a long while now. http://www.artima.com/weblogs/viewpost.jsp?thread=98196 http://www.artima.com/weblogs/viewpost.jsp?thread=98196

xi 16y ago

I, for one, prefer fors and ifs to high order functions when reading and writing Python code. I use the latter very sparingly and only when it does not violate the overall "pseudocode" feel of the code. For that, generator expressions and functions like `any`, `all`, `sum` are of great help. For example, I have nothing against the code like this: if any(foo.is_cond for foo in foos): do(bar) but I cringe when I see `import functools, operator`, `reduce` or complex nested list comprehensions. It may work better in ML-derived functional languages because function definitions there, both anonymous and named, are extremely lightweight. This part of the language is highly optimized by necessity as high order functions is the only way to express iteration and other control flow constructs. But in Python, though not particularly heavyweight, function definitions don't mix well with regular code. Also I'm not sure if the author is completely fair with his loop example. Add a few local variables, `break` or `continue`, and the high order form may actually become less intuitive.

RyanMcGreal 16y ago

I rarely use for loops in Python. Most of the time I use list comprehensions, which are much more terse and expressive than loops and, at least to me, are easier to parse than map/filter/reduce functions.

KirinDave 16y ago
Funny, that. List comprehensions are actually sytactically and semantically more difficult than folds, modulo your logic. Honestly, I suspect the Haskell style and the curious Python cultural disdain for real lambadas have far more to do with your confort than any absolute metric of comprehension.
- skm 16y ago
  Anyone who has disdain for real lambadas just doesn't know what they're missing: http://www.youtube.com/watch?v=5AfTl5Vg73A http://www.youtube.com/watch?v=5AfTl5Vg73A

deleted 16y ago

[deleted]