7 ms·

It seems to be pretty good at map, filter, any, all, reversed, reduce, zip, list comprehensions, dict comprehensions, lambdas, and closures. Granted, it would

It seems to be pretty good at map, filter, any, all, reversed, reduce, zip, list comprehensions, dict comprehensions, lambdas, and closures. Granted, it would be unusual to see all, or even most, of those in one place, but they see use enough that calling python bad a functional programming is a little odd. I'd say it's pretty good at functional work in the small while somewhat ill suited in the large.

Sirenos 11y ago
Just because it has those functions doesn't make it good at them. Have you ever seen a Pythonic program converted into functional style? It looks horrendous.
- aidos 11y ago
  I would imagine it depend on what extreme you take it to. You don't have pattern matching or tail recursion, which make certain styles impossible. There's a much better discussion over here http://stackoverflow.com/questions/1017621/why-isnt-python-very-good-for-functional-programming http://stackoverflow.com/questions/1017621/why-isnt-python-v...
- icebraining 11y ago
  If you define "functional style" as using immutable data structures, higher-order functions, avoiding side-effects and using referentially transparent variables, I think Python programs look fine, and I try to write all the code I can this way (although practicality beats purity). If you define "functional style" as writing Lisp or Haskell programs using Python syntax, I agree they look horrendous.
  - cutler 11y ago
    Or you can use Hy (http://hylang.org http://hylang.org) and write Python in Lisp syntax.
  - tome 11y ago
    Where did you get immutable data structures from in Python, and what do you do when every third party library you interact with uses mutable ones?
    - icebraining 11y ago
      Besides tuples, I mostly treat the standard data structures as if they were immutable, without relying on them actually being :) As for third-party libraries, very few of them actually mutate structures passed by my code, in my experience; if they do, I simply make a copy before passing it.
    - devishard 11y ago
      > Where did you get immutable data structures from in Python Here's my favored source (in the Standard Library) https://docs.python.org/2/library/collections.html#collections.namedtuple https://docs.python.org/2/library/collections.html#collectio... > and what do you do when every third party library you interact with uses mutable ones? That's situational; which library are you having a problem with? I haven't really had that problem (okay, sometimes the tooling around web frameworks do stupid things, but that's not common). Note that just because something is mutable doesn't mean you have to mutate it. Yes, Python doesn't as widely enforce non-mutation as Haskell, OCaml, etc., but that doesn't mean that suddenly all the Python programmers lost their minds and started mutating all the things. We're not savages.
      - tome 11y ago
        > Note that just because something is mutable doesn't mean you have to mutate it I agree, and I don't mutate it, but my third party libraries and my collegues functions will. Not all of them, but enough to introduce annoying bugs.
        devishard 11y ago
        This is why I asked, "Which library are you having a problem with?" You've claimed that third party libraries and your colleague's functions will mutate the data structures you pass them, but this has very rarely been my experience.
BWStearns 11y ago
Python list/dict comprehensions are awesome. The only other language I've seen that has comparably awesome comprehensions is Haskell which (opinion ahead) offers easier access to more power at the cost of some readability upfront. Sadly I've seen functional operations like map/filter/reduce etc discouraged in (commercial) projects I've worked on, though I guess there's a bit of an argument there for debugability (make it a word?) since hunting down side effects may be more onerous?
- sago 11y ago
  I think the logic was that comprehensions should replace map and filter for most cases. [fn(a) for a in seq] for example or [a for a in seq if pred(a)] and so map and filter are 'old'-style and deprecated. But I have to agree, I think that's not a clear benefit. For example map(fn, seq) and filter(pred, seq) are clearer. Once you get more complex, however, the comprehension syntax does shine. Comprehensions don't help at all with reduce, of course, which has been tidied out of __builtins__ now.
  - hvm 11y ago
    I think it's a matter of taste or what you're used to. I find the first two examples clearer than the map/filter ones. Are map and filter more concise? Yeah but only in this case. If you would need to do some processing, they would get messy fast because of a lambda.
    - emidln 11y ago
      In my experience, the more complicated processing ends up being composed up of smaller units (that are testable), and then map/filter remain the most clear way of representing the iteration. Using lambdas for non-trivial process is just as bad as throwing that same complicated processing into a list comp.
    - sago 11y ago
      I work with a lot of people who have never drunk the functional koolaid, professionally. They have to do an extra mental step with map or filter - "oh map, that's where the first argument is applied to each item in the second - I think - perhaps the second argument is applied to the first, right, Stack Exchange". More explicit is clearer, then. 'Clear' like beauty, is subjective. But productivity isn't. And whatever my personal feelings, the productivity of the team wins. On the second point. I agree. Python's lambdas are a code-smell, for me. Which I don't say lightly, I'm a Scheme/Lisp guy deep down. But they fundamentally work against the aesthetics of the Python language, imho. A local function declaration is much less fragile. But I would say that as code complexity increases, in my experience, comprehensions don't last long either. They've a narrow range of applicability before you get a big block of spaghetti code. Then it is much better to define a local function and, essentially, 'map' it (even if that 'map' is done as comprehension). Of course, YMMV.
Walkman 11y ago
It's really not good. Python is an imperative language and if you dig a little, you can find why [0]. The reduce function has been moved to functools module [1]. If you try to write in purely functional style in Python, you will have a bad time. [0]: http://python-history.blogspot.hu/2009/04/origins-of-pythons-functional-features.html http://python-history.blogspot.hu/2009/04/origins-of-pythons... [1]: https://docs.python.org/3.2/library/functools.html#functools.reduce https://docs.python.org/3.2/library/functools.html#functools...
- devishard 11y ago
  This is silly. You're pointing out some historical reasons why some functional features have been removed, nerfed, or moved out of __builtins__, but none of this is a discussion of problems you've come across with actually writing Python in a functional style. I've written tens of thousands of lines of code in a functional style in Python, and while it's different from Scheme and takes a little getting used to, Python is a very capable programming language for functional programming. It does lack tail call optimization, but I think you'd find that even in Scheme, most times where you would write a recursive function, you should be writing something with one of the higher-order functions. 99.9% of recursive functions contain a buggy hand-rolled implementation of map, reduce, or filter. Scheme is a more academic language, so it makes sense for them to include this feature, which gives language users the same power as the language creators. But Python is intended for professional development and as such, it makes sense to force users into a better style.
  - jarcane 11y ago
    Yes, Erlang is such a toy language[1], it's never used for "professional development" at all[2]. [1] http://learnyousomeerlang.com/recursion http://learnyousomeerlang.com/recursion [2] http://www.fastcompany.com/3026758/inside-erlang-the-rare-programming-language-behind-whatsapps-success http://www.fastcompany.com/3026758/inside-erlang-the-rare-pr...
    - devishard 11y ago
      > Yes, Erlang is such a toy language[1], it's never used for "professional development" at all[2]. From your sarcastic tone it seems like you take issue with something you think I've said, but since your post is unrelated to anything I actually said, I can only guess that you've inferred some meaning that isn't there.
xor-xor 11y ago
Are you sure about lambdas..? They are kind of crippled in comparison to almost any other language which has them.

Sirenos 11y ago

Just because it has those functions doesn't make it good at them. Have you ever seen a Pythonic program converted into functional style? It looks horrendous.

aidos 11y ago
I would imagine it depend on what extreme you take it to. You don't have pattern matching or tail recursion, which make certain styles impossible. There's a much better discussion over here http://stackoverflow.com/questions/1017621/why-isnt-python-very-good-for-functional-programming http://stackoverflow.com/questions/1017621/why-isnt-python-v...
icebraining 11y ago
If you define "functional style" as using immutable data structures, higher-order functions, avoiding side-effects and using referentially transparent variables, I think Python programs look fine, and I try to write all the code I can this way (although practicality beats purity). If you define "functional style" as writing Lisp or Haskell programs using Python syntax, I agree they look horrendous.
- cutler 11y ago
  Or you can use Hy (http://hylang.org http://hylang.org) and write Python in Lisp syntax.
- tome 11y ago
  Where did you get immutable data structures from in Python, and what do you do when every third party library you interact with uses mutable ones?
  - icebraining 11y ago
    Besides tuples, I mostly treat the standard data structures as if they were immutable, without relying on them actually being :) As for third-party libraries, very few of them actually mutate structures passed by my code, in my experience; if they do, I simply make a copy before passing it.
  - devishard 11y ago
    > Where did you get immutable data structures from in Python Here's my favored source (in the Standard Library) https://docs.python.org/2/library/collections.html#collections.namedtuple https://docs.python.org/2/library/collections.html#collectio... > and what do you do when every third party library you interact with uses mutable ones? That's situational; which library are you having a problem with? I haven't really had that problem (okay, sometimes the tooling around web frameworks do stupid things, but that's not common). Note that just because something is mutable doesn't mean you have to mutate it. Yes, Python doesn't as widely enforce non-mutation as Haskell, OCaml, etc., but that doesn't mean that suddenly all the Python programmers lost their minds and started mutating all the things. We're not savages.
    - tome 11y ago
      > Note that just because something is mutable doesn't mean you have to mutate it I agree, and I don't mutate it, but my third party libraries and my collegues functions will. Not all of them, but enough to introduce annoying bugs.
      - devishard 11y ago
        This is why I asked, "Which library are you having a problem with?" You've claimed that third party libraries and your colleague's functions will mutate the data structures you pass them, but this has very rarely been my experience.

BWStearns 11y ago

Python list/dict comprehensions are awesome. The only other language I've seen that has comparably awesome comprehensions is Haskell which (opinion ahead) offers easier access to more power at the cost of some readability upfront. Sadly I've seen functional operations like map/filter/reduce etc discouraged in (commercial) projects I've worked on, though I guess there's a bit of an argument there for debugability (make it a word?) since hunting down side effects may be more onerous?

sago 11y ago
I think the logic was that comprehensions should replace map and filter for most cases. [fn(a) for a in seq] for example or [a for a in seq if pred(a)] and so map and filter are 'old'-style and deprecated. But I have to agree, I think that's not a clear benefit. For example map(fn, seq) and filter(pred, seq) are clearer. Once you get more complex, however, the comprehension syntax does shine. Comprehensions don't help at all with reduce, of course, which has been tidied out of __builtins__ now.
- hvm 11y ago
  I think it's a matter of taste or what you're used to. I find the first two examples clearer than the map/filter ones. Are map and filter more concise? Yeah but only in this case. If you would need to do some processing, they would get messy fast because of a lambda.
  - emidln 11y ago
    In my experience, the more complicated processing ends up being composed up of smaller units (that are testable), and then map/filter remain the most clear way of representing the iteration. Using lambdas for non-trivial process is just as bad as throwing that same complicated processing into a list comp.
  - sago 11y ago
    I work with a lot of people who have never drunk the functional koolaid, professionally. They have to do an extra mental step with map or filter - "oh map, that's where the first argument is applied to each item in the second - I think - perhaps the second argument is applied to the first, right, Stack Exchange". More explicit is clearer, then. 'Clear' like beauty, is subjective. But productivity isn't. And whatever my personal feelings, the productivity of the team wins. On the second point. I agree. Python's lambdas are a code-smell, for me. Which I don't say lightly, I'm a Scheme/Lisp guy deep down. But they fundamentally work against the aesthetics of the Python language, imho. A local function declaration is much less fragile. But I would say that as code complexity increases, in my experience, comprehensions don't last long either. They've a narrow range of applicability before you get a big block of spaghetti code. Then it is much better to define a local function and, essentially, 'map' it (even if that 'map' is done as comprehension). Of course, YMMV.

Walkman 11y ago

It's really not good. Python is an imperative language and if you dig a little, you can find why [0]. The reduce function has been moved to functools module [1]. If you try to write in purely functional style in Python, you will have a bad time. [0]: http://python-history.blogspot.hu/2009/04/origins-of-pythons-functional-features.html http://python-history.blogspot.hu/2009/04/origins-of-pythons... [1]: https://docs.python.org/3.2/library/functools.html#functools.reduce https://docs.python.org/3.2/library/functools.html#functools...

devishard 11y ago
This is silly. You're pointing out some historical reasons why some functional features have been removed, nerfed, or moved out of __builtins__, but none of this is a discussion of problems you've come across with actually writing Python in a functional style. I've written tens of thousands of lines of code in a functional style in Python, and while it's different from Scheme and takes a little getting used to, Python is a very capable programming language for functional programming. It does lack tail call optimization, but I think you'd find that even in Scheme, most times where you would write a recursive function, you should be writing something with one of the higher-order functions. 99.9% of recursive functions contain a buggy hand-rolled implementation of map, reduce, or filter. Scheme is a more academic language, so it makes sense for them to include this feature, which gives language users the same power as the language creators. But Python is intended for professional development and as such, it makes sense to force users into a better style.
- jarcane 11y ago
  Yes, Erlang is such a toy language[1], it's never used for "professional development" at all[2]. [1] http://learnyousomeerlang.com/recursion http://learnyousomeerlang.com/recursion [2] http://www.fastcompany.com/3026758/inside-erlang-the-rare-programming-language-behind-whatsapps-success http://www.fastcompany.com/3026758/inside-erlang-the-rare-pr...
  - devishard 11y ago
    > Yes, Erlang is such a toy language[1], it's never used for "professional development" at all[2]. From your sarcastic tone it seems like you take issue with something you think I've said, but since your post is unrelated to anything I actually said, I can only guess that you've inferred some meaning that isn't there.

xor-xor 11y ago

Are you sure about lambdas..? They are kind of crippled in comparison to almost any other language which has them.