Hacker News new | ask | show | jobs
by yowlingcat 2181 days ago
I wonder if this is intentional. FP constructs are increasingly discouraged in Python, taking reduce [1] as an example. Not that this is necessarily a bad thing, per sé -- I think it does simplify the language. But it's an opinionated decision that will discourage FP enthusiasm from finding a home in Python.

[1] http://lambda-the-ultimate.org/node/587

5 comments

> I wonder if this is intentional. FP constructs are increasingly discouraged in Python, taking reduce [1] as an example.

That single comment from Guido 15 years ago, which was largely backtracked on—map and filter remain in the core library and reduce moved to a library in stdlib, lambda remains—is not really an example of something accurately described as “increasingly” now. In fact, given the backtracking, it's arguably decreasingly true from the high point of that post.

With a good mix of comprehensions, itertools, functools and lambda, there is enough stuff to get creative with FP in Python anyway.
btw, my favorite FP-hack: let-in expressions with lambdas OR list comprehensions:

  let x = foo in expr
can be

  [expr for x in (foo,)][0]
(kinda reads like a Haskell `where` clause!) or:

  (lambda x = foo: expr)()
useful in a pre-walrus-operator REPL :)
If you want to program in Haskell, why don’t you get a job programming in Haskell rather than inventing something so ugly?

You would not get through code review with that in any shop that has discipline.

> You would not get through code review with that in any shop that has discipline.

... and i'd never think to try! that's why i mentioned using it in a REPL and called it a hack :) it's just fun. i played around with bytecode-rewriting too, doesn't mean i'd use it in production.

PS. for a less extreme version, the 1-elem-tuple trick is useful if you need an intermediate variable in a listcomp:

  [
    y+y
    for x in my_list
    for y in (foo(x),)
  ]
but it's (obviously) ugly & only useful if you're in a REPL and don't want to rewrite the whole thing.
Yeah but constantly jumping between idioms means this is stuff I have to usually look up instead of just intuiting.
the Syntax section has a bit more:

> "[...] making it an expression would be inconsistent with other syntactic choices in Python. All decision making logic is expressed almost exclusively in statements, so we decided to not deviate from this."

so it's just keeping in line with Python's general imperativess.

> FP constructs are increasingly discouraged in Python [...] Not that this is necessarily a bad thing, per sé

i, on the other hand, do think it's a bad thing :) but what can you do...

> i, on the other hand, do think it's a bad thing :) but what can you do...

Hy[1] I guess? It looks pretty lively although I'm not sure how seriously people take it these days.

[1]: https://github.com/hylang/hy

Not sure about "increasingly" - note the comment you link to is 15 years old! It seems more like a recognition that map/filter/reduce never was idiomatic Python and there are better ways to do the same. Python have never tried to be a functional language.
BDFL made good points though.