4 ms·

"Pythonic functional" seems like a contradiction of terms, considering python's infamous hostility (e.g. http://fold.sigusr2.net/2010/03/guido-on-functional.htm

"Pythonic functional" seems like a contradiction of terms, considering python's infamous hostility (e.g. http://fold.sigusr2.net/2010/03/guido-on-functional.html http://fold.sigusr2.net/2010/03/guido-on-functional.html) to functional programming seems like a key part of what it means to be pythonic. That said, it looks a lot more pleasant than Python. The addition of pattern matching alone makes this seem like a very worthwhile project, a big improvement on Python.

sgillen 8y ago
I’m not sure what you mean, what about python is notoriously unfunctional?
- darkpuma 8y ago
  It's capable of functional programming in the sense that functions are first class values that you can pass around, but it is infamously hostile to functional programming. For example, python still doesn't have multi-line lambdas, and the justifications for why always boil down to it being "unpythonic". Furthermore over the years Guido has made it pretty clear that he doesn't particularly like or care about functional programming: https://python-history.blogspot.com/2009/04/origins-of-pythons-functional-features.html https://python-history.blogspot.com/2009/04/origins-of-pytho...
  - pseudalopex 8y ago
    Requiring complex functions to have names isn't hostile to functional programming.
    - darkpuma 8y ago
      It really is though. It doesn't prevent it, but it sure as shit doesn't encourage it.
      - fulafel 8y ago
        Allowing to elide the add42 from "def add42(x): x+42" makes the difference between encouraging FP or not? I've actually started wishing for the opposite change in my use of Clojure. There, it is currently optional to supply a name for the fn form. Always supplying the name, like in "(fn add-42 [x] (+ x 42))", would make stack traces more readable and the named function object would be easy to identify when it appeared in the REPL / pretty-printed data structures.
        darkpuma 8y ago
        > "Allowing to elide the add42 from "def add42(x): x+42" makes the difference between encouraging FP or not?" Not being able to define a two-line function in the place where it's used because you have to give it a name discourages FP in a way many other modern languages do not.
        stormking 8y ago
        Not really, since Python can nest functions: def something(x): def myfunc(y, z): ... return result reduce(myfunc, x) So the difference is like having to write x = some_very_complex_expression_that_can_get_quite_long some_function(x) instead of some_function(some_very_complex_expression_that_can_get_quite_long) In many cases this may make code even more readable. I'm not saying that Python's lambdas are perfect as they are or that multi-line lambdas would be a bad thing. I'm just saying it's not as bad as you paint it.
      - pseudalopex 8y ago
        It subtly discourages functional programming when a for loop would be faster and more readable.
        darkpuma 8y ago
        > more readable 'More readable' is subjective. It's clear that Guido and much of the Python community believe that FP is less readable, less pythonic, and that viewpoint is exactly the sort of hostility towards FP that I'm talking about. And in no small part this is a self-fulfilling attitude, e.g. "python lambdas are ugly because pythonistas believe FP is ugly." They're way uglier in python than in other languages. The ugliness of python's lambda is a trait of python, not a trait of FP, yet it's ugliness cited to justify itself. > when a for loop would be faster Hey, that's fine. But I think much of the time for the sort of things I'm working on, that's deep into "premature optimization" territory. I'd rather a slight linear slowdown with more readable code than a slight linear speedup with less readable code. I'd prefer that python not "subtly discourage" me to nudge me towards less readable code because a list comprehension is marginally more performant.
- AlexCoventry 8y ago
  The built-in data structures often force in-place mutation on code which wants to be in any way efficient.
lbarrow 8y ago
That quote is hilarious -- Guido von Rossum claims that it's impossible to implement `reduce` in a few lines in a functional language. Just out of curiosity, I checked out the `reduce` implementation in Elixir: def reduce(enumerable, fun) do result = Enumerable.reduce(enumerable, {:cont, :first}, fn x, :first -> {:cont, {:acc, x}} x, {:acc, acc} -> {:cont, {:acc, fun.(x, acc)}} end) |> elem(1) case result do :first -> raise Enum.EmptyError {:acc, acc} -> acc end end Seems pretty straightforward to me. https://github.com/elixir-lang/elixir/blob/v1.7.4/lib/elixir/lib/enum.ex#L1872-L1884 https://github.com/elixir-lang/elixir/blob/v1.7.4/lib/elixir...
- darkpuma 8y ago
  Exactly. In scheme reduce-left/fold-left can be as simple as: (define (reduce-left fn init lst) (if (null? lst) init (reduce-left fn (fn init (car lst)) (cdr lst)))) It's clear from that quote that Guido (at least at that time) doesn't have real experience with functional programming and is letting his personal biases cloud his judgement. Okay maybe '"scheme isn't a functional language because it allows side effects and only Haskell and family are allowed to call themselves functional", or whatever. He seems to perhaps hint at that mentality. But the fact remains that a language like scheme makes this much easier than python.
  - kbp 8y ago
    What do you mean by the last paragraph? foldl in Haskell is just foldl _ acc [] = acc foldl f acc (x:xs) = foldl f (f acc x) xs And in Python something like def foldl(f, acc, l): for x in l: acc = f(acc, x) return acc Which doesn't seem much harder to read or write than any other version, to me (it's all just syntax around the same algorithm).
fulafel 8y ago
I think you are conflating Guido's attitude to FP with Python too much here. All the FP primitives in Python were championed by other people. In your linked blog post, Guido is talking about purely functional languages and how Python, like Lisp, is not like that. Which is true but doesn't make Python bad for (or "hostile" to) writing functional code. In fact Python taught a generation of programmers to love functional code, because of the big speedup available from stringing together C-native builtins with higher order functions.
- darkpuma 8y ago
  There is "not purely functional", and then there is python. Python does more to discourage FP than other "not purely functional" languages. Guido may no longer be python's BDFL, but it's clear that during his tenure he had little interest in making python better FP. He accepted contributions (like the addition of lambda) from other people, but never did anything to champion FP in python and it really shows.
  - fulafel 8y ago
    Do you feel Python discourages FP more than eg C++, or JavaScript? I'd call Python more functional than either of those, and a little less functional than Common Lisp.
    - darkpuma 8y ago
      More than javascript, yes. C++ is not a language I'd say nice things about unless under duress.
    - walterstucco 8y ago
      Yes

sgillen 8y ago

I’m not sure what you mean, what about python is notoriously unfunctional?

darkpuma 8y ago
It's capable of functional programming in the sense that functions are first class values that you can pass around, but it is infamously hostile to functional programming. For example, python still doesn't have multi-line lambdas, and the justifications for why always boil down to it being "unpythonic". Furthermore over the years Guido has made it pretty clear that he doesn't particularly like or care about functional programming: https://python-history.blogspot.com/2009/04/origins-of-pythons-functional-features.html https://python-history.blogspot.com/2009/04/origins-of-pytho...
- pseudalopex 8y ago
  Requiring complex functions to have names isn't hostile to functional programming.
  - darkpuma 8y ago
    It really is though. It doesn't prevent it, but it sure as shit doesn't encourage it.
    - fulafel 8y ago
      Allowing to elide the add42 from "def add42(x): x+42" makes the difference between encouraging FP or not? I've actually started wishing for the opposite change in my use of Clojure. There, it is currently optional to supply a name for the fn form. Always supplying the name, like in "(fn add-42 [x] (+ x 42))", would make stack traces more readable and the named function object would be easy to identify when it appeared in the REPL / pretty-printed data structures.
      - darkpuma 8y ago
        > "Allowing to elide the add42 from "def add42(x): x+42" makes the difference between encouraging FP or not?" Not being able to define a two-line function in the place where it's used because you have to give it a name discourages FP in a way many other modern languages do not.
        stormking 8y ago
        Not really, since Python can nest functions: def something(x): def myfunc(y, z): ... return result reduce(myfunc, x) So the difference is like having to write x = some_very_complex_expression_that_can_get_quite_long some_function(x) instead of some_function(some_very_complex_expression_that_can_get_quite_long) In many cases this may make code even more readable. I'm not saying that Python's lambdas are perfect as they are or that multi-line lambdas would be a bad thing. I'm just saying it's not as bad as you paint it.
    - pseudalopex 8y ago
      It subtly discourages functional programming when a for loop would be faster and more readable.
      - darkpuma 8y ago
        > more readable 'More readable' is subjective. It's clear that Guido and much of the Python community believe that FP is less readable, less pythonic, and that viewpoint is exactly the sort of hostility towards FP that I'm talking about. And in no small part this is a self-fulfilling attitude, e.g. "python lambdas are ugly because pythonistas believe FP is ugly." They're way uglier in python than in other languages. The ugliness of python's lambda is a trait of python, not a trait of FP, yet it's ugliness cited to justify itself. > when a for loop would be faster Hey, that's fine. But I think much of the time for the sort of things I'm working on, that's deep into "premature optimization" territory. I'd rather a slight linear slowdown with more readable code than a slight linear speedup with less readable code. I'd prefer that python not "subtly discourage" me to nudge me towards less readable code because a list comprehension is marginally more performant.
AlexCoventry 8y ago
The built-in data structures often force in-place mutation on code which wants to be in any way efficient.

lbarrow 8y ago

That quote is hilarious -- Guido von Rossum claims that it's impossible to implement `reduce` in a few lines in a functional language. Just out of curiosity, I checked out the `reduce` implementation in Elixir: def reduce(enumerable, fun) do result = Enumerable.reduce(enumerable, {:cont, :first}, fn x, :first -> {:cont, {:acc, x}} x, {:acc, acc} -> {:cont, {:acc, fun.(x, acc)}} end) |> elem(1) case result do :first -> raise Enum.EmptyError {:acc, acc} -> acc end end Seems pretty straightforward to me. https://github.com/elixir-lang/elixir/blob/v1.7.4/lib/elixir/lib/enum.ex#L1872-L1884 https://github.com/elixir-lang/elixir/blob/v1.7.4/lib/elixir...

darkpuma 8y ago
Exactly. In scheme reduce-left/fold-left can be as simple as: (define (reduce-left fn init lst) (if (null? lst) init (reduce-left fn (fn init (car lst)) (cdr lst)))) It's clear from that quote that Guido (at least at that time) doesn't have real experience with functional programming and is letting his personal biases cloud his judgement. Okay maybe '"scheme isn't a functional language because it allows side effects and only Haskell and family are allowed to call themselves functional", or whatever. He seems to perhaps hint at that mentality. But the fact remains that a language like scheme makes this much easier than python.
- kbp 8y ago
  What do you mean by the last paragraph? foldl in Haskell is just foldl _ acc [] = acc foldl f acc (x:xs) = foldl f (f acc x) xs And in Python something like def foldl(f, acc, l): for x in l: acc = f(acc, x) return acc Which doesn't seem much harder to read or write than any other version, to me (it's all just syntax around the same algorithm).

fulafel 8y ago

I think you are conflating Guido's attitude to FP with Python too much here. All the FP primitives in Python were championed by other people. In your linked blog post, Guido is talking about purely functional languages and how Python, like Lisp, is not like that. Which is true but doesn't make Python bad for (or "hostile" to) writing functional code. In fact Python taught a generation of programmers to love functional code, because of the big speedup available from stringing together C-native builtins with higher order functions.

darkpuma 8y ago
There is "not purely functional", and then there is python. Python does more to discourage FP than other "not purely functional" languages. Guido may no longer be python's BDFL, but it's clear that during his tenure he had little interest in making python better FP. He accepted contributions (like the addition of lambda) from other people, but never did anything to champion FP in python and it really shows.
- fulafel 8y ago
  Do you feel Python discourages FP more than eg C++, or JavaScript? I'd call Python more functional than either of those, and a little less functional than Common Lisp.
  - darkpuma 8y ago
    More than javascript, yes. C++ is not a language I'd say nice things about unless under duress.
  - walterstucco 8y ago
    Yes