8 ms·

I'm just hoping this leads to a more multiparadigm Python that doesn't have a seemingly irrational fear of FP

by jrs95 8y ago

metalliqaz 8y ago
This comment puzzles me. For one, I can't recall meeting a stong FP proponent that accepts anything less than a language designed from the ground-up to be true FP. Second, how is Python afraid of FP? This[1] document has been part of the Python docs for as long as I can remember. [1] https://docs.python.org/2/howto/functional.html https://docs.python.org/2/howto/functional.html
- bluecalm 8y ago
  I love functional style and I think Python is very friendly to that style. You can make pure functions. You can use classes as store of values. Pass values and functions around as they are first class citizens. That you need some local state to implement a pure function isn't a problem as you can limit it to very simple things. Anonymous functions are not something you need either, just give it a name and pass it, wtp? I agree most of the "Python is not functional enough" criticism comes from people who just want as pure FP as possible.
- PurpleRamen 8y ago
  Some people think, because python is not fully embracing functional programming, it must fear it. Because anything less than 100% functional is not good enough. Namly the limited lambdas are always brought as a reason.
  - bad_user 8y ago
    Many programming languages these days have FP tendencies. However I can barely think of another mainstream and high level language that is more anti-FP than Python. And lambdas, in spite of popular opinion, have nothing to do with it ;-) (Actually I can think of another language that is more anti-FP than Python and that would be Go ... people saying Go is “pythonic” have it right)
    - joshuamorton 8y ago
      I'd be curious which of JavaScript, perl, js, and Ruby (and hell, go or Java, which are often considered high level) is more friendly to fp than python, and why, obviously. That's pretty much every other mainstream high level language ;) I've never heard anyone call go pythonic.
      - dragonwriter 8y ago
        > I'd be curious which of JavaScript, perl, js, and Ruby (and hell, go or Java, which are often considered high level) is more friendly to fp than python, and why, obviously. JS (which you listed twice), Perl (5 or 6), and in some ways Ruby (which is a mixed bag, because it doesn't actually have functions per se, but even so is in many ways more friendly to functional style than Python.) Being expression-oriented languages with full support for anonymous functions (callables in Ruby) and non-awkward creation of full (rather than read-only) closures are the main common factors.
        joshuamorton 8y ago
        Sorry, php, not js the second time. I'm not sure what you mean by read only closures, unless you mean a close which can later modify the enclosing scope, which python supports via the nonlocal keyword but also is decidedly bad, and not something I've ever before heard of as an fp concept. And as far as I can tell, your entire argument reduces to better lambdas. Which is what you said it wouldn't be. I feel misled. Oh wait you're a different user. Still this point stands. I wouldn't have responded if the expected answer was "better lambdas". You can do better. I guess the next important question is "what are the things you feel make a language functional, and why are those things valuable"? There are lots of aspects of functional programming that are good, I personally agree that anonymous functions are not one of them, especially when you have no need for callbacks (python doesn't really). And it's very possible to write functional code, imo, without anonymous functions. Why do you disagree.
        pmontra 8y ago
        Ruby has multi line lambdas and code blocks. Python doesn't. However we can't pass a function as argument (actually a method but it could be a def in a module). We can pass a symbol with the name of the fuction. We can pass the function in Python. I write very few classes in Python. I tend to write modules and import them. It's what I do in Elixir, obviously. However I don't write much Ruby code outside Rails and Rails is definitely object oriented and directs the developer to write OO code. Instead the most popular web framework for Python, Django, is almost anarchy, anything will do.
  - peatmoss 8y ago
    Most lisps are multiparadigm, and few would claim lisps are anti FP. I think Python is considered anti FP for two reasons: when suggestions to add more FP features have been raised, Guido has fairly unambiguously rejected those features. That’s all fine though. Python can do what Python wants. All else being equal, I’d prefer a little more functional flavor than Python has, but I won’t turn my nose up at writing Python if duty calls.
- bunderbunder 8y ago
  There has been some pushback on the inclusion of common functional idioms in Python, though. For example, GvR has expressed regret about allowing map, filter, etc. into Python, on the grounds that comprehensions are a more Pythonic way to accomplish most of the same stuff.
  - bluecalm 8y ago
    Aren't map and filter just redundant if you accept list comprehension as Pythonic thing to do?
    - jrs95 8y ago
      Maybe just map and filter but there are far more operations that can be done on these types than what is cleanly expressed in a comprehension.
  - metalliqaz 8y ago
    I assume it's because of this... Zen of Python: There should be one-- and preferably only one --obvious way to do it.
    - bunderbunder 8y ago
      True, but, if it were just that, I would expect Python to only have the map, filter, etc. functions, which have been in there since 1.0. List comprehensions were introduced much later, in version 2. That makes comprehensions the 2nd way to do it. They're also less obvious in my book, since their readability tends to drop precipitously once you start adding multiple "for" clauses to one.
  - somenewacc 8y ago
    But comprehensions are also a functional idiom.
    - lmm 8y ago
      The version Python has is awkward to work with, to the point that many Haskell programmers don't even realise it exists. The "do notation" style is much clearer than the "comprehension" style; unfortunately Python has no equivalent.
- jrs95 8y ago
  I’m not a strong FP proponent per se. I just really enjoy using things like Java 8 Streams, Lodash/Ramda, etc. Comprehensions are nice but they have a more limited scope than functions. Honestly the same can be said for decorators. Useful, but ultimately not much more useful than a plain old higher order function.
bad_user 8y ago
Python will never be FP friendly, even if there have been certain attempts in the past. The reason is that at its core Python is very statement and mutation oriented, instead of being expression oriented and to prefer immutability by default, like all FP languages are. People feel the need for example for anonymous functions that support statements but Python’s lambdas only support expressions and it turns out there’s not much you can do with those in Python. It’s the reason for why over the years Python acquired features for use cases that can normally be solved via higher order functions in other languages like Ruby. I think it is time to accept Python for what it is. A dirty, mutable language that gets the job done in certain contexts. Trying to change it I think does more harm than good.
- Areading314 8y ago
  As a corollary I think the lack of adoption of 'pure' languages, even after decades of trying, is evidence that they are just less productive than 'dirty' languages like python. Libraries and community are just much more important than the language itself.
  - nepeckman 8y ago
    I'd argue that the more pure FP languages have a higher learning curve, but that doesn't equate lower productivity. Plenty of people are productive in FP languages, and there are a good number of FP languages with decent adoption throughout the industry. They might not be as widely adopted as Python, but that's because it's really easy to learn Python.
    - throwaway5752 8y ago
      My experience is that pure FP languages have enormous individual productivity but that comes at the expense of lower team productivity/collaboration (my experience, even if not universal or even correct, is that in practice they are fairly idiomatic from developer to developer) and maintenance over time can be an issue for similar reasons. For simple systems and system management scripting, I will take the simpler language. That said, I'd want a very high concurrence system written in a function language over Python any day (gil notwithstanding). But I'm fine with Python not being that language.
rkangel 8y ago
I'm not a fan of 'multiparadigm'. As another comment on this branch says, the Zen of Python covers this quite well: > There should be one-- and preferably only one --obvious way to do it There are already 20 different ways of solving any given problem or of coding any given solution. At least if a single paradigm is used, then those familiar with it are unlikely to run into big surprises about how things are implemented. If your developers are used to an imperative style, a chunk of code in the middle of the codebase written in a strongly functional style is very difficult to comprehend. In one tool I wrote for work, I use function application to progressively transform a stream of events. It's a beautiful, neat solution to the problem, but confuses the hell out of everyone else because they've never written any Haskell. There are other ways to implement this that are just as clear and abstracted and maybe they take slightly more code, but it is code that is more maintainable by everyone else. Good code to me is not that which looks like it was coded by a genius, but that which looks like any child could have written it. For some code this is very hard, but I find it easier in Python than other languages. The more 'choices' that you have, the more inconsistency there will be about who chooses what. There is obviously a tradeoff here with giving developers the right tools for the job, but list comprehensions are a great example of how you can do that without having to use a different paradigm.
- coldtea 8y ago
  >> There should be one-- and preferably only one --obvious way to do it And then it offers 20 equally good ways: generators vs comprehensions vs iterators vs foreach loops vs map and filter, async vs threadpools vs processpools, and so on.
  - pfranz 8y ago
    It's tough to adhere to that principle, but its nice to see as a focus. Python wasn't even object oriented originally (and a lot of their standard library shows it). Guido has said he wishes he never added functional concepts like map and filter. Deprecating things hasn't been taken too well by the community.
    - 8y ago
rdtsc 8y ago
I am a fan of dynamic functional languages, I use them more than I use Python anyway. But I think Python should stick to being Pythonic. There should be less ways of doing the same thing not more. I don't even like the new assignment PEP because it just adds more complexity and more ways of doing the same thing. And knowing that it was the straw that broke the camel's back and pushed Guido away, makes me like it even less.
- bluecalm 8y ago
  There wasn't a way of doing list comprehensions where you use the same expression on the left and right side. You needed a for loop with a temporary variable to achieve it. I think it's much more useful than map/filter for example as those are redundant if you use list comprehensions.
- jrs95 8y ago
  I'm not talking about anything crazy here, just don't make map(), filter(), reduce() etc second class citizens and maybe even support tail call optimization. Honestly I don't know why comprehensions are so popular either, it's a slightly more convenient but less powerful construct than pure functions.
- ergothus 8y ago
  ...but people hating on the PEP (and refusing to accept their concerns had been considered) was the reason it drove him over the edge, so your post lamenting the issue is at the same time demonstrating the issue.

I'm just hoping this leads to a more multiparadigm Python that doesn't have a seemingly irrational fear of FP

by jrs95 8y ago

I'm just hoping this leads to a more multiparadigm Python that doesn't have a seemingly irrational fear of FP

This comment puzzles me. For one, I can't recall meeting a stong FP proponent that accepts anything less than a language designed from the ground-up to be true FP. Second, how is Python afraid of FP? This[1] document has been part of the Python docs for as long as I can remember. [1] https://docs.python.org/2/howto/functional.html https://docs.python.org/2/howto/functional.html

bluecalm 8y ago
I love functional style and I think Python is very friendly to that style. You can make pure functions. You can use classes as store of values. Pass values and functions around as they are first class citizens. That you need some local state to implement a pure function isn't a problem as you can limit it to very simple things. Anonymous functions are not something you need either, just give it a name and pass it, wtp? I agree most of the "Python is not functional enough" criticism comes from people who just want as pure FP as possible.
PurpleRamen 8y ago
Some people think, because python is not fully embracing functional programming, it must fear it. Because anything less than 100% functional is not good enough. Namly the limited lambdas are always brought as a reason.
- bad_user 8y ago
  Many programming languages these days have FP tendencies. However I can barely think of another mainstream and high level language that is more anti-FP than Python. And lambdas, in spite of popular opinion, have nothing to do with it ;-) (Actually I can think of another language that is more anti-FP than Python and that would be Go ... people saying Go is “pythonic” have it right)
  - joshuamorton 8y ago
    I'd be curious which of JavaScript, perl, js, and Ruby (and hell, go or Java, which are often considered high level) is more friendly to fp than python, and why, obviously. That's pretty much every other mainstream high level language ;) I've never heard anyone call go pythonic.
    - dragonwriter 8y ago
      > I'd be curious which of JavaScript, perl, js, and Ruby (and hell, go or Java, which are often considered high level) is more friendly to fp than python, and why, obviously. JS (which you listed twice), Perl (5 or 6), and in some ways Ruby (which is a mixed bag, because it doesn't actually have functions per se, but even so is in many ways more friendly to functional style than Python.) Being expression-oriented languages with full support for anonymous functions (callables in Ruby) and non-awkward creation of full (rather than read-only) closures are the main common factors.
      - joshuamorton 8y ago
        Sorry, php, not js the second time. I'm not sure what you mean by read only closures, unless you mean a close which can later modify the enclosing scope, which python supports via the nonlocal keyword but also is decidedly bad, and not something I've ever before heard of as an fp concept. And as far as I can tell, your entire argument reduces to better lambdas. Which is what you said it wouldn't be. I feel misled. Oh wait you're a different user. Still this point stands. I wouldn't have responded if the expected answer was "better lambdas". You can do better. I guess the next important question is "what are the things you feel make a language functional, and why are those things valuable"? There are lots of aspects of functional programming that are good, I personally agree that anonymous functions are not one of them, especially when you have no need for callbacks (python doesn't really). And it's very possible to write functional code, imo, without anonymous functions. Why do you disagree.
      - pmontra 8y ago
        Ruby has multi line lambdas and code blocks. Python doesn't. However we can't pass a function as argument (actually a method but it could be a def in a module). We can pass a symbol with the name of the fuction. We can pass the function in Python. I write very few classes in Python. I tend to write modules and import them. It's what I do in Elixir, obviously. However I don't write much Ruby code outside Rails and Rails is definitely object oriented and directs the developer to write OO code. Instead the most popular web framework for Python, Django, is almost anarchy, anything will do.
- peatmoss 8y ago
  Most lisps are multiparadigm, and few would claim lisps are anti FP. I think Python is considered anti FP for two reasons: when suggestions to add more FP features have been raised, Guido has fairly unambiguously rejected those features. That’s all fine though. Python can do what Python wants. All else being equal, I’d prefer a little more functional flavor than Python has, but I won’t turn my nose up at writing Python if duty calls.
bunderbunder 8y ago
There has been some pushback on the inclusion of common functional idioms in Python, though. For example, GvR has expressed regret about allowing map, filter, etc. into Python, on the grounds that comprehensions are a more Pythonic way to accomplish most of the same stuff.
- bluecalm 8y ago
  Aren't map and filter just redundant if you accept list comprehension as Pythonic thing to do?
  - jrs95 8y ago
    Maybe just map and filter but there are far more operations that can be done on these types than what is cleanly expressed in a comprehension.
- metalliqaz 8y ago
  I assume it's because of this... Zen of Python: There should be one-- and preferably only one --obvious way to do it.
  - bunderbunder 8y ago
    True, but, if it were just that, I would expect Python to only have the map, filter, etc. functions, which have been in there since 1.0. List comprehensions were introduced much later, in version 2. That makes comprehensions the 2nd way to do it. They're also less obvious in my book, since their readability tends to drop precipitously once you start adding multiple "for" clauses to one.
- somenewacc 8y ago
  But comprehensions are also a functional idiom.
  - lmm 8y ago
    The version Python has is awkward to work with, to the point that many Haskell programmers don't even realise it exists. The "do notation" style is much clearer than the "comprehension" style; unfortunately Python has no equivalent.
jrs95 8y ago
I’m not a strong FP proponent per se. I just really enjoy using things like Java 8 Streams, Lodash/Ramda, etc. Comprehensions are nice but they have a more limited scope than functions. Honestly the same can be said for decorators. Useful, but ultimately not much more useful than a plain old higher order function.

bad_user 8y ago

Python will never be FP friendly, even if there have been certain attempts in the past. The reason is that at its core Python is very statement and mutation oriented, instead of being expression oriented and to prefer immutability by default, like all FP languages are. People feel the need for example for anonymous functions that support statements but Python’s lambdas only support expressions and it turns out there’s not much you can do with those in Python. It’s the reason for why over the years Python acquired features for use cases that can normally be solved via higher order functions in other languages like Ruby. I think it is time to accept Python for what it is. A dirty, mutable language that gets the job done in certain contexts. Trying to change it I think does more harm than good.

Areading314 8y ago
As a corollary I think the lack of adoption of 'pure' languages, even after decades of trying, is evidence that they are just less productive than 'dirty' languages like python. Libraries and community are just much more important than the language itself.
- nepeckman 8y ago
  I'd argue that the more pure FP languages have a higher learning curve, but that doesn't equate lower productivity. Plenty of people are productive in FP languages, and there are a good number of FP languages with decent adoption throughout the industry. They might not be as widely adopted as Python, but that's because it's really easy to learn Python.
  - throwaway5752 8y ago
    My experience is that pure FP languages have enormous individual productivity but that comes at the expense of lower team productivity/collaboration (my experience, even if not universal or even correct, is that in practice they are fairly idiomatic from developer to developer) and maintenance over time can be an issue for similar reasons. For simple systems and system management scripting, I will take the simpler language. That said, I'd want a very high concurrence system written in a function language over Python any day (gil notwithstanding). But I'm fine with Python not being that language.

rkangel 8y ago

I'm not a fan of 'multiparadigm'. As another comment on this branch says, the Zen of Python covers this quite well: > There should be one-- and preferably only one --obvious way to do it There are already 20 different ways of solving any given problem or of coding any given solution. At least if a single paradigm is used, then those familiar with it are unlikely to run into big surprises about how things are implemented. If your developers are used to an imperative style, a chunk of code in the middle of the codebase written in a strongly functional style is very difficult to comprehend. In one tool I wrote for work, I use function application to progressively transform a stream of events. It's a beautiful, neat solution to the problem, but confuses the hell out of everyone else because they've never written any Haskell. There are other ways to implement this that are just as clear and abstracted and maybe they take slightly more code, but it is code that is more maintainable by everyone else. Good code to me is not that which looks like it was coded by a genius, but that which looks like any child could have written it. For some code this is very hard, but I find it easier in Python than other languages. The more 'choices' that you have, the more inconsistency there will be about who chooses what. There is obviously a tradeoff here with giving developers the right tools for the job, but list comprehensions are a great example of how you can do that without having to use a different paradigm.

coldtea 8y ago
>> There should be one-- and preferably only one --obvious way to do it And then it offers 20 equally good ways: generators vs comprehensions vs iterators vs foreach loops vs map and filter, async vs threadpools vs processpools, and so on.
- pfranz 8y ago
  It's tough to adhere to that principle, but its nice to see as a focus. Python wasn't even object oriented originally (and a lot of their standard library shows it). Guido has said he wishes he never added functional concepts like map and filter. Deprecating things hasn't been taken too well by the community.
  - 8y ago

rdtsc 8y ago

I am a fan of dynamic functional languages, I use them more than I use Python anyway. But I think Python should stick to being Pythonic. There should be less ways of doing the same thing not more. I don't even like the new assignment PEP because it just adds more complexity and more ways of doing the same thing. And knowing that it was the straw that broke the camel's back and pushed Guido away, makes me like it even less.

bluecalm 8y ago
There wasn't a way of doing list comprehensions where you use the same expression on the left and right side. You needed a for loop with a temporary variable to achieve it. I think it's much more useful than map/filter for example as those are redundant if you use list comprehensions.
jrs95 8y ago
I'm not talking about anything crazy here, just don't make map(), filter(), reduce() etc second class citizens and maybe even support tail call optimization. Honestly I don't know why comprehensions are so popular either, it's a slightly more convenient but less powerful construct than pure functions.
ergothus 8y ago
...but people hating on the PEP (and refusing to accept their concerns had been considered) was the reason it drove him over the edge, so your post lamenting the issue is at the same time demonstrating the issue.